Rockbox Development > Feature Ideas

gap detect

(1/3) > >>

dryrock:
In the FAQ, in the section on gapless playback, is this:

Other players cut off any zero data (or near zero data) in the final frame of an MP3. This method, which is sometimes referred to as "gap detect" or "gap delete," is not truly gapless, because (1) is it not accurate, and (2) it will cut off silence that is supposed to be at the end of a track. "Gapless" will play back MP3s of a CD the way the mastering engineer intended it to be; "gap detect" or "gap delete" will not. For example, if the mastering engineer decided to put a 2-second gap between one song and another on a CD, true gapless playback will retain that 2-second gap, whereas gap detect or gap delete will not. Rockbox uses gapless playback, not gap detect or gap delete.

I am trying to understand exactly what is wrong with doing this other than the fact that rockbox can't know for sure whether it's the right thing to do.

My feeling is that if you are cutting off zero data in the final frame only, the risk of error is infinitesimally small. Obviously you would only do this if the frame is not ALL zeroes. You're talking about removing a maximum of what, 1/13 second of silence (576 samples at 8khz)? Removal of an extra tiny bit of silence is going to be MUCH less audible in many cases than insertion of that same amount of extra silence.

The part about the 2-second gap is also a bit misleading - again we are talking about not removing ALL trailing silence, just in the last frame. In the absence of knowing what the mastering engineer wanted, I think it is more correct to omit that silence than include it.

The advantage of doing this is that we don't need to worry about how our mp3's were encoded. If the proper LAME information is there, use it, and don't do any trimming. But if it's not, I personally am willing to give up 1/13 second of intentional silence to avoid hearing 1/13 second of unintentional silence. And making it an option gives the user control.

Llorean:
Or just encode your files properly, and it's not a problem.

dryrock:
I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 

If I can spend a couple hours patching rockbox to improve my experience, that's a big gain over re-encoding a bunch of my old mp3's (granted, by coincidence, I used lame to encode most of the ones that need gapless).

saratoga:

--- Quote from: dryrock on January 11, 2011, 01:36:13 PM ---I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 
--- End quote ---

MP3 encoders have been gapless for a decade now.  You're welcome to add support for this, but its a lot of work for something thats really not that useful to most people.

bluebrother:

--- Quote from: dryrock on January 11, 2011, 01:36:13 PM ---I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 
--- End quote ---

This leaves one question open: which software in the process encoding - decoding should make life easier? The encoding software or the decoding one? Since you usually encode less often than you decode I'd vote for the encoder.

Navigation

[0] Message Index

[#] Next page