I've been having problems with lame `randomly' writing `incorrect' Xing
headers. I finally figured out that it's not random (it's my fault) and lame
isn't writing incorrect Xing info, but no info at all. What's been going on? I
start up lame
lame -k -v -V 0 -b 160 -B 320 foo.wav foo.mp3
and then while lame is still compressing, do an
mv foo.mp3 bar.mp3
lame is obviously doing the right thing by putting in a LAME block in place of
the Xing block so it can come back later and fill it in with the correct info,
but it seems lame is closing the mp3 when it is finished compressing and then
re-opening it to write the Xing info.
Now, while I will admit this might be a "don't do that" type of thing, I still
feel that this is a bug as lame should be more robust than that. I guess not
enough people rip CDs by hand to notice this :/. In the meantime, I'll change
my habits, but I thought this problem should be reported.
Bill
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
