> > 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? > With our without the "-t", the file sizes of the decoded .wav should be the same. ARe you getting the message: "Oops: first frame of mpglib output will be lost" ? This means that when the initialization routine was checking for the Xing header, it accidently read enough data to decode the first frame. But the initialization routines are not allowed to return MP3 data which means this data is lost. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
