Does Rockbox support '.cue' files for mp3's?

[pupil]

It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.

[jaybeee]

It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.

Really? I've never had a problem myself.  I use foobar & slimserver as my players without any problems. 

It's the bitrate that varies not the time, so why should it be a problem?  Or is it that the palyer's code converts the time in a cue sheet into samples (588) and that could confuse it if it's VBR?

[Llorean]

It doesn't rule out Ogg Vorbis because the format has much better seeking.
It really only makes seeking bad for MPC and VBR MP3. Those are the only two that would experience problems with next-track / previous-track seeks in a .CUE situation.

Since the bitrate varies throughout the file, and you have to seek by data position, not time position (as that would require decoding the whole file up to where you wanted to seek), varying bitrate poses difficulties. I believe that Vorbis has information in place to facilitate this, if I understand.

[saratoga]

Keep in mind, skipping most likely would not work on VBR/ABR MP3 files, so you'd be limited to CBR file only in such a system.

You mean skipping to the next track or seeking through the currently played track? 
If it really can't be done on vbr files then that is a big problem for cue sheet handling.  I mean that rules out Ogg Vorbis for a start. 

The issue here is that fast seeking in VBR requires a container like Ogg, MP4 or MKA.  MP3 doesn't have that.

It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.

Werid.  The handful of CUEs people have given me have all been for VBR files.  What would be the point of taking such care to use CUE, and then doing a bad encode with CBR?  Totally defeats the purpose IMO.

It's the bitrate that varies not the time, so why should it be a problem?

Because CUE is really, really dumb and stores the position in the file in time, not bytes.  So to figure out which btyes map to which seconds, you need to decode the file.

I suppose thats not really fair since cue wasn't really meant to work the way people use it, but whatever.

[bobbel]

IMHO it would be great to implement .cue support.
Would save time not to split those single .cue/mp3(or flac) for rockbox

bobbel 

[esper256]

Sometimes music is about convenience not technical superiority.

What is the technical superiority of a remote control for your receiver? You can walk up to it and press buttons on the thing. So why should we waste money when we buy receivers when they include a remote?

.cue file is:

A) convenient for those that have a music collection that uses .cue files

In my own experience I use cue/wav for certain reasons

A) The much touted LAME gaplessness of multiple tracks isn't something that every mp3 file I've ever played works flawlessly. The support is just not out universal, so don't treat multi-mp3 files as a perfect gapless solution. cue/mp3 IS perfectly gapless.

B) cue/mp3 represents the music collection better. The people who say it's unnecessary probably don't listen to dance music. Dance music relies on gaplessness. If you don't listen to a lot of DJmixes you probably wouldn't even know if your gapless playing was even really gapless. If you have a collection that is heavy in dance music and DJ mixes you will have many 60 - 200 minute MP3 liveset recordings/radio recordings where anywhere between 9 and 40 individual songs are played.

There are two supporting reasons for mp3/cue:
1. Splitting the mp3 file makes no sense from a music collection perspective. Because a DJ played Artist A - Track T in Liveset L, if you have it as one file, your collection tells you you have Liveset L in your collection. If you have it split, suddenly you are told you have Artist A - Track T in your collection. You don't. There could be an MC hollering over it, it could have fade out fade ins where commercials were removed. From my perspective about being OCD about music organization, storing the original full length MP3 file makes the most sense from a music collection standpoint

2. In a hypothetical situation where we concede that we are selfish but are allowed to not transcode our entire collection to bow to Rockbox's whims: cue files are a great way to add ease of use to our huge MP3 files. Given that we 100% refuse to split our long mp3 files, cue files give us the following features:

#1 and the biggest 1, when a DJ slams a new track in that is absolutely amazing, and I go, man who's track is this, it's ridiculous good, I look at my player and instead of saying I'm 41 minutes into DJ nobodycares, it says Artist A - Track T, and I try to remember to buy that song later.

#2 when the DJ trainwrecks into that one song of the album that has that annoying voice sample over and over again, but the rest of the album is really great but you don't like this song, you hit the next button, and you are pleasantly relieved of having to listen to it.

#3 there are two sides to this one. Sometimes in a radio set, a DJ will play a song that is unreleased, or a special version that might never ever get played ever again. You are in love with it, and you want to listen to it right away, you'd have to seek all over the place in a long mp3 file, but with cue file you can jump right to that place in the mix.  The other way to look at this is if you are playing long mix and you accidentally hit stop or track change button and you lose your place, with cue file you can at least get back to the nearest track mark very quickly.

#4 these DJ mixes I mentioned, not only make more sense in your collection as one file, but with a correct cue implementation, the cue file should always insert itself into the playlist as a whole entity. As in you shouldn't be able to reorder it, or drag a new track in betwee the tracks. If we simply split them up, then various play methods would actually do just this. Rockbox wouldn't read our minds and know that when we add our entire collection to the playlist and hit shuffle, don't shuffle these split mp3s because they came from an mp3/cue situation, it would shuffle them. I hate hearing mixed songs shuffled.

Seeking in VBR due to cue being inaccurate is 100% acceptible.

If you are simply ripping normal CDs (as in a cd that you would want to listen to the tracks non-contiguosly very often) as mp3/cue then I'd agree with Llorean, what's the point? But if your music is only really truly represented as one file, and cue just helps manage playing that file then it makes sense in my opinion.

To reword that, there's little sense in implementing cue support so that it makes cues not work any different than already sliced mp3s. In my opinion cues should be treated like one long track with benefits. But that is because of my musical bias.

I'm an old hand straight C coder and I'd consider giving this a shot, except that I have a good feeling it will interefere with the way the rest of Rockbox handles playlist entries in memory and wouldn't want to guess at what would be the best way to alter that to allow 1 file -> multi play-list entryish formats.

[saratoga]

A) The much touted LAME gaplessness of multiple tracks isn't something that every mp3 file I've ever played works flawlessly. The support is just not out universal, so don't treat multi-mp3 files as a perfect gapless solution. cue/mp3 IS perfectly gapless.

Within the context of Rockbox, LAME is gapless, so this isn't really an arguement. 

Actually, given that I don't believe there is even a single hardware device out there that can understand CUE files, wouldn't your argument actually favor not using CUE files?  Seems to me that if support must be universal for something to be acceptable to you, then CUE would not be acceptable since support is so poor.

B) cue/mp3 represents the music collection better. The people who say it's unnecessary probably don't listen to dance music. Dance music relies on gaplessness. If you don't listen to a lot of DJmixes you probably wouldn't even know if your gapless playing was even really gapless. If you have a collection that is heavy in dance music and DJ mixes you will have many 60 - 200 minute MP3 liveset recordings/radio recordings where anywhere between 9 and 40 individual songs are played.

I don't see how its better, given that both are functionally identical. 

1. Splitting the mp3 file makes no sense from a music collection perspective. Because a DJ played Artist A - Track T in Liveset L, if you have it as one file, your collection tells you you have Liveset L in your collection. If you have it split, suddenly you are told you have Artist A - Track T in your collection. You don't.

If you tag properly, this is not a problem.

2. In a hypothetical situation where we concede that we are selfish but are allowed to not transcode our entire collection to bow to Rockbox's whims: cue files are a great way to add ease of use to our huge MP3 files. Given that we 100% refuse to split our long mp3 files, cue files give us the following features:

#1 and the biggest 1, when a DJ slams a new track in that is absolutely amazing, and I go, man who's track is this, it's ridiculous good, I look at my player and instead of saying I'm 41 minutes into DJ nobodycares, it says Artist A - Track T, and I try to remember to buy that song later.

#2 when the DJ trainwrecks into that one song of the album that has that annoying voice sample over and over again, but the rest of the album is really great but you don't like this song, you hit the next button, and you are pleasantly relieved of having to listen to it.

#3 there are two sides to this one. Sometimes in a radio set, a DJ will play a song that is unreleased, or a special version that might never ever get played ever again. You are in love with it, and you want to listen to it right away, you'd have to seek all over the place in a long mp3 file, but with cue file you can jump right to that place in the mix.  The other way to look at this is if you are playing long mix and you accidentally hit stop or track change button and you lose your place, with cue file you can at least get back to the nearest track mark very quickly.

#4 these DJ mixes I mentioned, not only make more sense in your collection as one file, but with a correct cue implementation, the cue file should always insert itself into the playlist as a whole entity. As in you shouldn't be able to reorder it, or drag a new track in betwee the tracks. If we simply split them up, then various play methods would actually do just this. Rockbox wouldn't read our minds and know that when we add our entire collection to the playlist and hit shuffle, don't shuffle these split mp3s because they came from an mp3/cue situation, it would shuffle them. I hate hearing mixed songs shuffled.

Seeking in VBR due to cue being inaccurate is 100% acceptible.

If you are simply ripping normal CDs (as in a cd that you would want to listen to the tracks non-contiguosly very often) as mp3/cue then I'd agree with Llorean, what's the point? But if your music is only really truly represented as one file, and cue just helps manage playing that file then it makes sense in my opinion.

To reword that, there's little sense in implementing cue support so that it makes cues not work any different than already sliced mp3s. In my opinion cues should be treated like one long track with benefits. But that is because of my musical bias.

I'm an old hand straight C coder and I'd consider giving this a shot, except that I have a good feeling it will interefere with the way the rest of Rockbox handles playlist entries in memory and wouldn't want to guess at what would be the best way to alter that to allow 1 file -> multi play-list entryish formats.

Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.

[jaybeee]

@esper256: you must have a very similar musical bias like me 

And if it's that VBR mp3s cannot be supported by cue sheets in Rockbox but CBR can, then have a butchers at this nifty little tool I've been using for a while: MP3packer.

Yes it's a step to perform that could be replaced by splitting files, but as esper256 says, I don't think people want to have two copies of a 'mix' (the single file and the split files). I know I don't

Anyway, just a bit more info and a nice little tool for you.

---

It's a long shot, but how about implementing MP3packer into Rockbox for when you want to allow seeking of a VBR mp3? Again, I don't expect this to be taken up by Dev etc, but if you don't ask/suggest you don't get 

[Bagder]

how about implementing MP3packer into Rockbox

This is deviating from the thread topic, but sure go ahead and write a plugin for Rockbox that does this if you think it is a useful thing. Personally I've never had a need.

[jaybeee]

how about implementing MP3packer into Rockbox

This is deviating from the thread topic, but sure go ahead and write a plugin for Rockbox that does this if you think it is a useful thing. Personally I've never had a need.

deviating? yes, slighty.  But still sort of relevant.
Anyway, it was just a suggestion* thrown into the mix

* a suggestion for others to see, cos I'll not be writing any plugins for Rockbox; I've donated instead and hope that helps (not this issue, but Rockbox in general)

[esper256]

Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.

Yes I read the thread. Did you read my post? Given that I said VBR support isn't important to the people who most likely want Cue/MP3 support I'm guessing you didn't.

You can call my reasons "semi-valid" and I will call your argument simply the absence of my musical tastes. If you had, then you would want cue/mp3 too. So maybe the workaround for us is to start listening to more top40 on rockbox.

Thank you for your enlightening reply.

[saratoga]

Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.

Yes I read the thread. Did you read my post? Given that I said VBR support isn't important to the people who most likely want Cue/MP3 support I'm guessing you didn't.

It probably won't work at all for VBR files.  I can't imagine theres much interest in a solution that won't work for the overwhelming majority of files.  Yes, it could work for CBR, but given that it won't work most of the time, a better solution is needed IMO.

You can call my reasons "semi-valid" and I will call your argument simply the absence of my musical tastes.

Tastes have nothing to do with this.  Everything you wanted can be accomplished already in Rockbox presently, though it might take some effort to set things up.  Furthermore, the present situation will work for VBR files.  Which is why I called your points "semi-valid".

If you had, then you would want cue/mp3 too. So maybe the workaround for us is to start listening to more top40 on rockbox.

I don't know what this means.

[ted_b]

First post.  I registered because I want to regoster this issue.

I have 780 FLAC files representing 780 cd's (so far).  Each has been ripped with EAC and each has a related cue sheet file.  I did this to easily archive and manage (rather than 10,000 files, assuming 12 songs per album), and because popular programs like Foobar2k handle flac and cue sheets out of the box.  It's painless, convenient (there's that word again) and oh.....what a lot of people who have large collections do (780 represents a portion of my library, and I'm a smalltime collector).

I can't become a Rockbox user unless:
a) I listen to albums in their entirety without the ability to distinguish tracks, read track titles, and skip along based on track numbers, etc.
2)  rerip 780 FLAC files into 10,000 new individual flac song files, all the while deleting the album files (unless I have an addtl few hundred gig laying around).

Seems unlikely.  So I vote for cue sheet support, too.  Thx
Ted

[Llorean]

Don't *vote* for it. Either do it, or don't complain about lack of it.

Rockbox is not a democracy. It's a bunch of stuff that got done by people who decided they wanted it enough to actually DO it.

So, which is more inconvenient for you? Reripping your songs, or learning to program in C and writing CUE support for us? If the reripping is more inconvenient, we'd certainly welcome an effective method of CUE support.

[ted_b]

your not serious, really?  I assumed this was a forum for questions, help, field-initiated ideas....... and feature requests.  My first post here and I'm told
"either program in C or shut up."  Wow.

Bye