Thank You for your continued support and contributions!
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.
Quote from: saratoga on June 07, 2006, 03:26:51 PMKeep 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.
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.
It's the bitrate that varies not the time, so why should it be a problem?
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.
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.
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.
how about implementing MP3packer into Rockbox
Quote from: jaybeee on July 07, 2006, 04:38:03 AMhow about implementing MP3packer into RockboxThis 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.
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.
Quote from: saratoga on July 06, 2006, 08:32:36 PMDid 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.
Page created in 0.127 seconds with 22 queries.