Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC "Add ID3 Tag" seems to change the data unexpectedly... (Read 5206 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

I have been experimenting with EAC and Lame recently, and enjoyed reading the useful guides on here.
I do have a query, however, regarding how EAC adds its own tags - specifically ID3v1.1
As an experiment, I used EAC to rip a song in 3 different ways:

(1) With no tags
(2) With an ID3v1.1 tag set by LAME only, using the relevant switches in the parameter box
(3) With an ID3v1.1 tag set by EAC only, checking the "Add ID3 tag" box (and clearing out the tag switches in the parameter box)

I used the vbr "-v 2" mode, and did not allow any ID3v2 tags. When binary-comparing the mp3s, I found the following:

As expected, MP3s (1) and (2) were identical, byte for byte, except that (2) had the extra 128 bytes at the end for the ID3v1.1 tag.
But MP3s (2) and (3) differed in 4 bytes: addresses 51, 52, 191, 192.

The same thing happened when repeating the test on another song.

So EAC is adjusting something when it adds its own ID3v1.1 tag... Is it adjusting audio data, or something in the header?
After searching online, I found this on the EAC site: "EAC now corrects the VBR header of MP3 files after writing its ID3 tags".
Unfortunately, it doesn't give any further details.

Any ideas gratefully received,
Sam.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #1
Why not simply use a program like mp3tag to see what differences there are in tags and then foobar2000's compare feature to make sure the audio data is the same?

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #2
Why not simply use a program like mp3tag to see what differences there are in tags and then foobar2000's compare feature to make sure the audio data is the same?


Thanks for replying. The tags are identical in the tests I've done. The bytes that are changed are either part of the audio, or more likely the LAME header, assuming it's over 192 bytes long. It's always bytes 51, 52, 191, 192 that are affected. Do you know what information is stored here? Or is it audio data after all?

Sam

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #3
>The tags are identical in the tests I've done.
I know for a fact that the tags will not be identical.  What did you use to check them?

>Do you know what information is stored here?
I don't, but if the audio decodes the same way then why does it matter?

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #4
>The tags are identical in the tests I've done.
I know for a fact that the tags will not be identical.  What did you use to check them?

>Do you know what information is stored here?
I don't, but if the audio decodes the same way then why does it matter?


I used "TSBinComp", a freeware binary file comparison utility to compare the files byte by byte. The only differences between the MP3s were at the 4 addresses mentioned, near the beginning of the files. The rest, including the 128 bytes at the end where the ID3v1.1 tags are, was absolutely identical.

Good point about the audio perhaps decoding the same - I'll try decompressing them and comparing the WAVs.

Thanks,
Sam

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #5
Bytes 191 and 192 are the CRC16 of the tag, so since bytes 51 and 52 are different, that makes the CRC different.

EDIT: Bytes 51 and 52 are in the table of contents, so the calculated value of a TOC entry had a slightly different value.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #6
Other than my suggesting to that you compare audio data, please ignore what I've said about the tags.  I was mindlessly comparing V2.3.  The discussion is in better hands with pdq.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #7
Thanks both of you for the info.

What is the TOC (table of contents??) for in an mp3 file? Does it allow players like Winamp to "navigate" around somehow?

Perhaps this is a little bug in EAC, with it changing the TOC like this when adding an ID3v1.1 tag.

Sam.


PS: I have just decompressed all three MP3s from my first post, and compared the WAVs with EAC. All three are identical (hooray!).

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #8
Bytes 191 and 192 are the CRC16 of the tag, so since bytes 51 and 52 are different, that makes the CRC different.

EDIT: Bytes 51 and 52 are in the table of contents, so the calculated value of a TOC entry had a slightly different value.


By my calculations bytes 51 and 52 are part of a long value in the vbr header that indicates the stream size.
I did not think that an id3 tag length was included in this however may be in this case.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #9
What is the TOC (table of contents??) for in an mp3 file? Does it allow players like Winamp to "navigate" around somehow?

Unlike in a CBR file, you can't go to a random time in a VBR file by simply calculating how many bytes in from the start of the file to go. To allow random access that is more accurate than you would get by assuming equal spacing, the encoder notes how many bytes in to go for a number of time values within the file (the table of contents). You can then interpolate between these values to get pretty close, if not exactly, to where you wanted to go.

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #10
Theoretically. In practice the TOC is useless if you care about precise, sample accurate seeking.
Full-quoting makes you scroll past the same junk over and over.

 

EAC "Add ID3 Tag" seems to change the data unexpectedly...

Reply #11
I know this is an old thread, but this problem has continued with EAC for well over 3 years now.

I recently discovered that all 150+ CD's I ripped and encoded using EAC and LAME since 2009 have incorrect VBR headers.

I discovered this because the music player in my new Audi can't fast-forward or resume any of these files, and abruptly cuts off the ends of long tracks.

As the OP mentioned, the EAC changelog from June 29, 2007 says "EAC now corrects the VBR header of MP3 files after writing its ID3 tags".

I've spent a great deal of time confirming this using MP3Diags, MP3val and fixmbr. In all cases, it flags these files has having an incorrect VBR header. Instead of showing the length of the audio file LAME produced, the headers show the entire length of the mp3, including all tags. If I prevent EAC from writing any tags, then the VBR header has the correct length.

I tried various versions of LAME, and it doesn't have any effect. All versions of EAC through 0.95 appear to be fine. Every EAC version after that has the problem, regardless of which LAME version I use.

I know I can just continue to run vbrfix on every file I create, but I'd rather get to the bottom of this.

Am I the only one who has noticed this problem?