-Brading Software Message Board
+--Forum: Mp3/Tag Studio Support and Bug Reports
+---Topic: VBR header inconsistant since using EAC started by TokyoElbow
Posted by: Elbow on Sep. 24 2002,09:09
Me again,
I have just noticed all my new rips / encodes are all showing red errors with the Length and Frames.
If this is something to do with EAC (exact audio copy) should I repair the VBR headers or leave them as is?
Im using the alt preset standard setting (Lame).
Seems I always have 2 problems at once
Cheers again
Posted by: Disposable Hero on Sep. 24 2002,10:43
This is a known issue, the VBR tags don't get written properly - though I am unsure if this is the case with all recent compiles. The VBR Header repair should work fine on these. The flaw should be gone when the next stable (non-alpha) iteration of LAME appears.
Posted by: Elbow on Sep. 24 2002,14:38
Ah ok,
Do I NEED to repair the VBR header?
What problems will ocure if I dont?
Cheers
Posted by: Magnus Brading on Sep. 24 2002,18:23
The immediate problems that might result from having faulty VBR headers are that you cannot seek properly in the file while playing it in an mp3 player, and also the wrong playlength might be displayed. Of course this might lead to other errors, depending on the software used to play/view the mp3 files in question.
My guess would be that the length of the file is only calculated a few bytes off or so, and then you won't notice these problems. But that's just my guess, I haven't heard anything about it myself. In any case, you have nothing to lose by repairing them though.
Posted by: Disposable Hero on Sep. 24 2002,20:27
The VBR problem can lead to incorrect reporting of the file's bitrate and incorrect reporting of the playlength. The variation can be extreme - I did a test after TokyoElbow's post, ripping a track with EAC and LAME at --alt-preset extreme, then browsed it in MP3TS. True playlength was 7min 36sec, reported playlength was around 14min. Reported bitrate was 128. As Magnus mentioned, this can cause issues with seek and with playback depending on the decoder.
I rush to mention that this is not an MP3TS problem or even an EAC problem. Also, the VBR fix in MP3TS does completely correct this error in the files that I tested, and does so quickly.
EDIT: an actual answer to TokyoElbow's questions
There doesn't appear to be any drawback to applying the VBR fix, but there might be problems if the files are not fixed. Since it's a quick operation and will become unnecessary with future versions of LAME, I say go for it - after testing on copies, of course
Posted by: EddyGeez on Sep. 24 2002,23:36
What version of EAC are you using?
I had this problem with an earlier beta of EAC, but it was corrected in more recent betas.
It was actually an EAC problem. I had EAC configured to write an ID3v2.3 tag after the extracted .wav file was encoded by LAME. EAC was somehow corrupting the VBR tag when it added the ID3v2 tag. Andre corrected the problem, and I hope it hasn't "reappeared" in a newer release of EAC.
Posted by: Disposable Hero on Sep. 25 2002,21:09
EddyGeez: for folks without a lot of EAC experience, could you post a short walkthrough of fixing/configuring this? Menuname, Option Tab, which checkbox, etc. I'm sure that would help a lot and be most appreciated
Posted by: Elbow on Sep. 26 2002,02:11
---------------------QUOTE-------------------
What version of EAC are you using?
---------------------QUOTE-------------------
Im at work right now but with a quick search I believe it to be
Exact Audio Copy V0.9 beta 4
In fact Im 99% sure its that one, well 100%.
I joined a group called < Uber Node > and they give you a reg file to set up EAC.
Quality of encodes has been increased a hell of a lot.
I did pop this question of inconsistant vbr headers on their forum but only got one reply to it:
---------------------QUOTE-------------------
if you mean you are encoding lame mp3 with EAC, then yes I've had a couple of times where the lame vbr header is corrupt.
It tells you this is the case in Encspot. You can also see the problem in Winamp - instead of the bitrate fluctuating between the prescribed mp3 bitrate intervals (160,192,224 etc) - it fluctuates around the average by intervals of one (eg 182,181,183).
I think the problem stems either from
a) having too many simulaneous ripping / coding threads going on, or
b)using encspot to read mp3 files while they are still EAC temp - eg before it has finished - think this might be corrupting them.
---------------------QUOTE-------------------
BTW where did Magnus get that 'I am not worthy' smilie?
I cant see it anywhere!!!
Posted by: Magnus Brading on Sep. 26 2002,14:24
You can bring up a "card" with more smilies if you click on the "emoticons" link just under the message edit box when you write a post.
Posted by: Elbow on Sep. 26 2002,15:46
I checked the VBR headers with EncSpot and they appear ok. So is it MP3 TS?
Posted by: EddyGeez on Sep. 26 2002,18:35
Hrmph.
Indeed, I just verified that with EAC 0.9 beta 4 and the encoder set to lame 3.92 --alt-preset standard (the recommended setting by the LAME developers) with "Add ID3 tag" checked that the resulting MP3 has red Length and Frames in Mp3/TS.
If I uncheck the "Add ID3 tag" in EAC, the resulting MP3 shows "correct" Length and Frames in Mp3/TS (they aren't red), so to me, this points to another problem with EAC's ID3v2 tagging.
Now, here is something that is very interesting...
If I use the Mp3/TS Shell Extension menu, right-click on an MP3 file and choose "Copy tag > Copy all tag data", and then right-click the file that shows non-red Length and Tag frames and choose "Paste tag > Overwrite all previous tag data", the Length and Frames fields now show up as red in Mp3/TS!
Something weird is definitely going on with adding tags to VBR files, and it appears that maybe both EAC and Mp3/TS are having issues. (Indeed, the "VBR Repair" option can correct whatever the error is so the Length/Frame fields are no longer red, but that step should not be necessary.)
Posted by: Magnus Brading on Sep. 26 2002,18:53
When an mp3 file is tagged, and it had no previous tag in it, the file size changes slightly (this goes for both ID3v1 and ID3v2 tags). Since the exact filesize is stored inside the VBR-header, it then becomes incorrect. That is why it shows up as red in Mp3/TS in that case.
This is what I guessed was the problem earlier in this thread, but as I also said then, this will practically not affect playback or seek properties at all, because the difference is relatively small.
So, we seem to talk about two different problems. First the tagging issue, which is not that serious, and second the bug in that encoder, which seems to be more serious and mess up the VBR tag completely.
Posted by: Elbow on Sep. 27 2002,04:02
OK so what are we saying here in plain English? (sorry Jargon has gone right over my head)
Its EAC that is causing this problem?
If so to fix this all I need to do is follow EddyGeez post and uncheck the "Add ID3 tag" in EAC ?
Sorry for my incompatability in this matter but I am learning honest.
Thanks to you all
Posted by: Magnus Brading on Sep. 27 2002,15:58
According to the discussions earlier in this thread there is a problem in (earlier versions of?) EAC, causing serious VBR-header corruption if writing ID3v2 tags with EAC.
There is also always a problem with the small filesize changes caused in files whenever writing ID3v2 tags to them, no matter what program is used, but this does not corrupt the VBR header (as in the EAC case), it just renders the values in it slightly inexact. Even though they are slightly inexact this problem should cause no problems with playback or seeking, but Mp3/TS will still report them as incorrect (red), since they are incorrect, however little.
In the first case, with the EAC problem, you will need to repair the VBR header to obtain correct playback behavior, but in the second case there is no definite need for it.
So, all clear now?
Posted by: thei on Nov. 25 2002,18:36
Just a quick reply... having used most versions of both EAC and LAME, I have found that the VBR headers as reported in red in MP3TS are only technically innacurate, as Magnus said, a few bytes wrong, almost certainly due to the addition of the tag itself. In other words, it makes no difference if you correct it or not (except that the red will go away
) If it really bugs you, try using LAME to do the ID3 tags instead of EAC, as Eddy said. You can pass the tags to LAME via the encoding string.
end