Rockbox Development > Feature Ideas
gap detect
dryrock:
Think of it in terms of old-fashioned analog recording. Obviously when you make a recording you want to do the best job you can, to make it easy to make playback sound the best. Down the road a stretch, for playback, you want equipment that you can adjust to make the most of the recordings you have, rather than telling you you were a dolt for not doing something different when you recorded it and that the only way to make it sound better is to re-record it.
Let's say you had a tape deck that did not have Dolby noise reduction and you recorded a bunch of albums on it. Then you get a tape deck with Dolby NR and some other audio improvements. You can re-record all your albums to take advantage of the new tech, but most people won't. They'll count on the other improvements to make the most of their existing recordings.
So I kind of think the opposite of what you said. The process you do more often -- decode -- should be easier (make up for the deficiencies of the process you do less often).
saratoga:
--- Quote from: dryrock on January 11, 2011, 04:51:39 PM ---So I kind of think the opposite of what you said. The process you do more often -- decode -- should be easier (make up for the deficiencies of the process you do less often).
--- End quote ---
Most people won't agree with your assessment, but if it works for you, thats good enough. Submit a patch for doing gap detection properly and I'll try and find time to review it.
dryrock:
I have a little different appreciation for this question now...
Adding in code to chop off zeroes at the end of the last frame was quite simple. But I kept hearing this gap between my test tracks.
In my debugging it became clear that the last frame had no trailing zeroes (or close to zeroes). So why am I still hearing this gap?
Other tracks encoded with lame, or ogg tracks, were playing perfectly gaplessly.
So I opened up the test tracks with Audacity and what do I see?
There is approximately a full frame of silence at the BEGINNING of each of these tracks. Why the heck would an mp3 encoder do THAT??? (I believe these were ripped directly from cd to mp3 with a recent version of itunes).
So I pulled out some other old tracks. These I knew I had as wavs and had used itunes to convert to mp3 (it was the path of least resistance at the time). They similarly have a gap at the BEGINNING (and it appears possibly at the end).
Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.
saratoga:
--- Quote from: dryrock on January 14, 2011, 11:04:42 AM ---There is approximately a full frame of silence at the BEGINNING of each of these tracks. Why the heck would an mp3 encoder do THAT??? (I believe these were ripped directly from cd to mp3 with a recent version of itunes).
--- End quote ---
Because the filterbank used in mp3 has several hundred samples of delay at the beginning:
http://lame.sourceforge.net/tech-FAQ.txt
--- Quote from: dryrock on January 14, 2011, 11:04:42 AM ---Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.
--- End quote ---
We already do this:
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22872
dryrock:
--- Quote from: saratoga on January 14, 2011, 11:24:39 AM ---
--- Quote from: dryrock on January 14, 2011, 11:04:42 AM ---There is approximately a full frame of silence at the BEGINNING of each of these tracks. Why the heck would an mp3 encoder do THAT??? (I believe these were ripped directly from cd to mp3 with a recent version of itunes).
--- End quote ---
Because the filterbank used in mp3 has several hundred samples of delay at the beginning:
http://lame.sourceforge.net/tech-FAQ.txt
--- End quote ---
Ok, so if I understand things correctly, in the absence of a LAME header specifying the exact number of extra samples at the beginning, the decoder just skips a pre-set amount. So what I am hearing in my badly-encoded tracks is the remaining ~540 zero-ish samples.
When I import the mp3 into Audacity, Audacity may not skip any of the beginning samples. It is close to a full frame of zero-ish data at the beginning.
--- Quote from: saratoga on January 14, 2011, 11:24:39 AM ---
--- Quote from: dryrock on January 14, 2011, 11:04:42 AM ---Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.
--- End quote ---
We already do this:
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22872
--- End quote ---
Cool! It appears that my itunes-encoded test files predate this feature in itunes's encoding.
The end result is that as of now, I have routines to optionally chop off zero-ish data at the beginning of the first, or end of the last, frame. Audibly it has fixed my issue and I get gapless mp3 playback now with my bad mp3's -- and it doesn't appear to screw up lame-encoded ones :-) I need to do some cleanup before I submit any patches.
I do still have some stupid tracks that were converted to WMA automatically by WMP and those are going to get re-ripped to mp3 by modern software. But I don't have to re-rip all the ones I did using iTunes in the old days.
Thank you for your patience as I learned my way around.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version