Hello mr. Mark Taylor,

This feature is GREAT! When the WAV t/4 header bug is fixed, The
"live-cd" ripping problem is fixed just about perfectly:
-it doesn't matter that the file is a bit longer (trailing padding
bits), because then with the .cue will start the tracks at the right
point, and only the last track will be extended a bit ...

my suggestions:
- please add: IF frame#1==XingInfoHeader then skip some more samples:
22SEC-~1 WAV     3,889,664  05-19-00  3:53a 22sec-cep.wav
22SEC-~2 WAV     3,893,996  05-20-00  4:34p 22sec-cep_383_vbr.mp3.wav
22SEC-~4 WAV     3,889,388  05-20-00  4:52p 22sec-cep_383_vbr_notag.mp3.wav
PIEK     WAV     1,621,608  05-20-00  4:58p piek.wav
PIEKMP~1 WAV     1,626,860  05-20-00  4:59p piek.mp3.wav
PIEK_N~1 WAV     1,622,252  05-20-00  4:59p piek_notag.mp3.wav

the "-t" decoded mp3 always is closest to the original wav length,
because 1 extra "0-frame" is decoded when the tag is in front.

- why is my "22sec-cep_383_vbr_notag.mp3.wav" smaller than
"22sec-cep.wav"?  Is some trailing silence already cut? Are you sure
about that 1104 number?

Thanks for the great work!

-- 
Best regards,
 Roel                          mailto:[EMAIL PROTECTED]


--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to