IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Header identification issues, layer I and III in one file? :-S
Prodoc
post Nov 22 2011, 16:34
Post #1





Group: Members
Posts: 241
Joined: 16-October 03
Member No.: 9335



I found several files where the identification of the MP3 header is possibly incorrect. At least two completely different CD rips contain two or three tracks where the files are marked to be MPEG 1 layer I, based on the first found frame header. All the other files of the rips are marked MPEG 1 layer III, as they should be.

The library I'm using is TagLib#. Other applications like mp3check and foobar2000 mark the files to be MPEG 1 layer III as they should.
TagLib# is basing all it's information on just the first found header. I know this isn't a save method, but I'd like to find out what is going wrong with the first header. Two to three tracks having this issue on multiple discs is too much of a coincidence imho.

I've analysed two different files and found the following:
  • Only the first header is marked "layer I", all others are "layer III"
  • Both first headers do not have identical other flags
  • The first header is located at an offset behind what should be the size of the ID3v2 tag
  • Most other headers, though not all, have the same bitrate
  • Only one of the first headers has the CRC bit set

Some more details of one of the files:
First header: FF FE 08 50 (11111111 11111110 00001000 01010000)
Second header: FF FB E2 04 (11111111 11111011 11100010 00000100)

Most important aspects of the headers compared:
  • layer I - layer III
  • Protected by CRC - Not protected
  • bitrate free - bitrate 320
  • 32000 Hz - 44100 Hz
  • Joint stereo (Stereo) - Stereo

Below is the data from the first found header until the second found (in uppercase on the first and last line).
CODE
...
000103c1 | ff ff FF FE 08 50 6b 40 82 46 29 22 a8 c3 08 8c c7 82 10 13 1f 3c 4c 3d 62 3c e1 08 08
000103de | 42 94 0d 94 a1 22 0f 20 6c 65 2b 5d f9 75 d0 a8 6f d2 08 24 da 41 32 89 02 37 39 8c 4a
000103fb | 2c 48 84 2d e5 e8 2d fe 97 e7 6d f6 4f a8 cc 15 1f 8e d2 d1 5d 94 ab 05 04 43 29 53 d1
00010418 | 2a c6 0d a3 a4 99 9a 31 c0 fc 8e a8 25 36 60 8c 0b 99 03 45 89 38 54 c0 a8 88 a3 d0 3a
00010435 | 2d 20 5d 68 c5 1b 8a 20 49 ca a3 3c 2b 42 44 4e 4f 6a 1b 43 c9 58 8c a6 dd b3 54 99 2b
00010452 | 04 11 46 44 55 a4 ca 30 42 8f 5e 88 a9 11 e6 d1 2a 65 19 fc 9a 5c 98 fa 6d 62 27 a4 42
0001046f | d2 f5 64 88 4e 22 58 48 81 d2 41 18 19 c7 e3 d0 37 a4 09 6d 56 c1 63 6b e3 32 9c 18 b2
0001048c | c4 08 50 d2 8c d2 03 04 ef 5d 54 2c 0e 29 34 97 56 9e b5 be 90 11 7c 62 d1 b2 e4 d8 64
000104a9 | 56 a2 86 60 ac 58 41 7a a4 26 4b 35 49 e0 b4 96 22 37 8c 42 0e 18 f3 27 89 7b 58 30 83
000104c6 | 1a b9 7b 87 27 11 4f b2 29 23 d3 c9 de a6 b0 3d c1 11 da e0 5d 13 ca 19 3b 1b a5 80 69
000104e3 | 2e aa aa 2c d3 49 73 7f dc c7 4e 71 ad 40 94 b1 68 8a 58 4b dd c9 2b c0 cd e2 17 a4 6f
00010500 | ed 2c cc cc fd 3d ee d9 d5 cb 72 bf 86 aa 4b 56 19 0a 2a bc 4b 99 14 a8 2b 39 23 85 04
0001051d | e8 d9 03 1c 2c c1 8b 89 19 83 72 25 d6 c3 68 1e 6b 12 55 a2 26 66 b2 a2 34 5e e7 46 95
0001053a | e8 57 55 82 ed ac 74 e8 98 b2 32 70 f1 31 56 26 85 31 03 31 c5 a2 89 99 a5 a9 8a da 45
00010557 | 6f 83 45 85 28 3b 97 15 97 8c fb 7a 88 52 e4 28 d0 49 eb aa 7a ce 35 48 54 66 d3 c4 5e
00010574 | 05 06 51 21 82 dd 03 48 3b 4e a5 64 4e c2 9d 32 b3 59 b9 3c ea a2 86 36 42 0d 80 92 07
00010591 | 1c d3 cd 63 58 d4 92 96 26 b2 98 b4 22 2c 24 53 20 76 d6 56 f2 4b 4e 2b b8 27 0e 97 4f
000105ae | 56 ab 30 ec a8 b5 4b 0a 8f 16 11 38 a4 a6 71 a1 d6 37 08 25 85 0e 06 f2 b1 d7 a1 90 c3
000105cb | 80 51 49 c7 4d 02 5a f4 02 39 51 fa 32 22 43 34 d1 51 08 69 5b 8c bd 23 99 6c ab 18 2d
000105e8 | 3e 2b d3 cd 33 ce ce c8 62 36 ae d2 d1 61 1f 9d a3 c2 7e bd 1c 47 54 17 6b 49 e6 05 09
00010605 | ad a4 a8 ce 18 3c de 98 65 b9 94 38 24 10 c0 b8 ae 42 93 66 13 92 c2 8c 20 7b e6 b5 89
00010622 | 10 a9 ee e0 aa 02 3b 8d ae 4a cc 99 60 69 26 98 7e 3c 3c 7a 2a 1b 63 b0 e9 1d 30 6c 9d
0001063f | 98 9c 73 9c b9 14 65 17 c9 54 0b a2 42 61 46 e1 64 8b a2 61 41 5b f5 02 90 f0 75 69 db
0001065c | b8 e9 0b 06 86 b1 27 d2 cb 29 24 d5 8a f7 71 62 0f 27 9b 83 ec 12 c9 8c 36 50 d4 12 b6
00010679 | 94 33 3c 2b 06 57 c6 3a d0 d4 4c 96 4d cc 6a cc 9f 67 2f 4a 75 e6 c2 da 86 53 96 cd 58
00010696 | f8 d6 e7 74 d3 d0 db 26 FF FB E2 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...

What is this first found "frame" about?

Can it be that a possible VBR header frame does not have the same crucial flags as the other "normal" MP3 frames?

Is it just as well a valid MP3 frame or is it something else and could it safely be discarded?

If I change the code to only retrieve information from the first header found which has an identical following one (not taken stuff like bitrate into account), it would mean the frame above would be discarded. Would I not be taking the risk to discard a VBR header, since that's supposed to be located in the first frame?

This post has been edited by Prodoc: Nov 22 2011, 16:47
Go to the top of the page
+Quote Post
[JAZ]
post Nov 22 2011, 19:03
Post #2





Group: Members
Posts: 1797
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Do you have an ID3v2 tag with album art in that file? I am guessing that what you see is not a header, but something that fools the tagger. It is not valid in a stream to switch between mpeg layers.
I don't think it's the VBR table, because the VBR table is inside a frame.
Go to the top of the page
+Quote Post
Prodoc
post Nov 22 2011, 20:59
Post #3





Group: Members
Posts: 241
Joined: 16-October 03
Member No.: 9335



QUOTE ([JAZ] @ Nov 22 2011, 19:03) *
Do you have an ID3v2 tag with album art in that file?

Yes, it has an embedded jpg, the same as the other ripped files which do get recognized correctly.
Also, the complete ID3v2 size is set to:
CODE
00 04 05 4D

Which means until an offset of 102CD. The first frame is found behind this offset, as you can see from the hex code in my initial post, thus past the ID3v2 tag, including the embedded picture.

I have removed the picture to see if it made any difference, but unfortunately it did not. The same result can be reproduced after re-adding the picture.

QUOTE ([JAZ] @ Nov 22 2011, 19:03) *
I don't think it's the VBR table, because the VBR table is inside a frame.

Do you mean that you can see that it is not a valid frame?
Go to the top of the page
+Quote Post
[JAZ]
post Nov 23 2011, 20:08
Post #4





Group: Members
Posts: 1797
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



No. My last sentence was meant to say that the VBR header is designed to be inside a frame, and in this case, the parser should not see its data as another frame.

I am unsure on what is the data you've pasted. FF FB does look as valid (i guess it starts with silence, and that's why most of the data after this is zero). The data before does not look like a vbr header, since the vbr header contains a map of 100 points onto the stream, and i see no increasing of values in there.

if you could do some more tests maybe directly with the commandline instead of using a frontend and not put any id3 data, that might help to identify the strange data.
Go to the top of the page
+Quote Post
Prodoc
post Nov 24 2011, 20:51
Post #5





Group: Members
Posts: 241
Joined: 16-October 03
Member No.: 9335



QUOTE ([JAZ] @ Nov 23 2011, 20:08) *

if you could do some more tests maybe directly with the commandline instead of using a frontend and not put any id3 data, that might help to identify the strange data.

Sure, which tests do you have in mind. Also, what do you mean by "not put any id3 data"? Removing the ID3 tag(s) completely first?
Go to the top of the page
+Quote Post
db1989
post Nov 24 2011, 20:54
Post #6





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



No, “directly with the commandline instead of using a frontend and not put any id3 data” means to encode some other MP3s from the command-line without adding tags.
Go to the top of the page
+Quote Post
Prodoc
post Nov 24 2011, 23:05
Post #7





Group: Members
Posts: 241
Joined: 16-October 03
Member No.: 9335



QUOTE (db1989 @ Nov 24 2011, 20:54) *
No, “directly with the commandline instead of using a frontend and not put any id3 data” means to encode some other MP3s from the command-line without adding tags.

I think it will be nearly impossible to reproduce MP3s that will be causing the same issues.
The MP3s which have the issue are encodes from a long time back. Where one release is encoded using a Xing encoder, the other uses e.g. a FhG encoder. It is therefore not limited to a specific encoder, nor do I have a clue which version of a specific encoder I used at the time.

What I could do is rip e.g. two of the discs again to wav, and see if the latest lame encoder will produce the same issue. If this does not result in the same issue, it'll be looking for a needle in a hay stack, not to mentioned weeks of work, re-encoding my complete collection.

If I was to use the lame encoder by cli, are there any specific flags, besides the default encoding parameters, I should use to produce more data to actually have something to analyse?

This post has been edited by Prodoc: Nov 24 2011, 23:05
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: 22nd December 2014 - 13:58