IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
EAC "Add ID3 Tag" seems to change the data unexpectedly...
samcruise
post Sep 23 2010, 19:48
Post #1





Group: Members
Posts: 4
Joined: 23-September 10
Member No.: 84092



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.

This post has been edited by samcruise: Sep 23 2010, 19:50
Go to the top of the page
+Quote Post
greynol
post Sep 23 2010, 19:52
Post #2





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
samcruise
post Sep 23 2010, 20:01
Post #3





Group: Members
Posts: 4
Joined: 23-September 10
Member No.: 84092



QUOTE (greynol @ Sep 23 2010, 19:52) *
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
Go to the top of the page
+Quote Post
greynol
post Sep 23 2010, 20:24
Post #4





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



>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?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
samcruise
post Sep 23 2010, 20:53
Post #5





Group: Members
Posts: 4
Joined: 23-September 10
Member No.: 84092



QUOTE (greynol @ Sep 23 2010, 20:24) *
>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

This post has been edited by samcruise: Sep 23 2010, 20:56
Go to the top of the page
+Quote Post
pdq
post Sep 23 2010, 21:07
Post #6





Group: Members
Posts: 3304
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



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.

This post has been edited by pdq: Sep 23 2010, 21:09
Go to the top of the page
+Quote Post
greynol
post Sep 23 2010, 21:20
Post #7





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
samcruise
post Sep 23 2010, 21:24
Post #8





Group: Members
Posts: 4
Joined: 23-September 10
Member No.: 84092



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!).

This post has been edited by samcruise: Sep 23 2010, 21:25
Go to the top of the page
+Quote Post
alondon
post Sep 23 2010, 21:42
Post #9





Group: Members
Posts: 62
Joined: 13-October 09
Member No.: 73985



QUOTE (pdq @ Sep 23 2010, 22:07) *
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.
Go to the top of the page
+Quote Post
pdq
post Sep 23 2010, 22:00
Post #10





Group: Members
Posts: 3304
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



QUOTE (samcruise @ Sep 23 2010, 16:24) *
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.
Go to the top of the page
+Quote Post
Yirkha
post Sep 23 2010, 22:08
Post #11





Group: FB2K Moderator
Posts: 2359
Joined: 30-November 07
Member No.: 49158



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.
Go to the top of the page
+Quote Post
Dave42
post Feb 17 2013, 21:17
Post #12





Group: Members
Posts: 1
Joined: 17-February 13
Member No.: 106709



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?
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 23:18