Rockbox General > Rockbox General Discussion
Does Rockbox support '.cue' files for mp3's?
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:
--- Quote from: esper256 on July 06, 2006, 07:17:20 PM ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
I don't see how its better, given that both are functionally identical.
--- Quote ---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.
--- End quote ---
If you tag properly, this is not a problem.
--- Quote ---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.
--- End quote ---
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 ;D
Bagder:
--- Quote from: jaybeee on July 07, 2006, 04:38:03 AM ---how about implementing MP3packer into Rockbox
--- End quote ---
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:
--- Quote from: Bagder on July 07, 2006, 07:14:54 AM ---
--- Quote from: jaybeee on July 07, 2006, 04:38:03 AM ---how about implementing MP3packer into Rockbox
--- End quote ---
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.
--- End quote ---
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)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version