Info/Xing tag: Should a decoder insist on zeroes after header?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Info/Xing tag: Should a decoder insist on zeroes after header?

Thomas Orgis
Hi,

as maintainer of mpg123, I got a user request to make my parser code
for the Xing/Info/Lame tag less strict. I so far assumed the picture given by

        http://gabriel.mp3-tech.org/mp3infotag.html

and every other file I saw so far is correct, namely that there is no
junk between the MPEG header and the Info tag data:

00000000  ff fb 90 c4 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 58 69 6e  67 00 00 00 0f 00 00 0c  |.....Xing.......|
00000020  ad 00 0e 3e 20 00 03 06  08 0a 0d 0f 12 14 17 19  |...> ...........|
00000030  1c 1e 20 23 26 28 2a 2c  2f 31 34 36 38 3b 3d 40  |.. #&(*,/1468;=@|
00000040  43 45 48 4b 4d 50 52 55  57 5a 5c 5e 61 64 66 69  |CEHKMPRUWZ\^adfi|
00000050  6c 6f 72 75 78 7b 7e 82  85 87 8a 8d 8f 92 95 98  |lorux{~.........|
00000060  9b 9e a1 a4 a7 aa ad b0  b3 b6 b9 bc bf c1 c4 c7  |................|
00000070  ca cd d0 d3 d6 d9 dc df  e1 e2 e4 e6 e7 e9 ea ec  |................|
00000080  ee f0 f2 f5 f7 f8 fa fb  fe 00 00 00 39 4c 41 4d  |............9LAM|
00000090  45 33 2e 39 36 72 03 b4  00 00 00 00 2e 15 00 00  |E3.96r..........|
000000a0  34 20 24 08 40 41 00 01  cc 00 0e 3e 20 64 f0 8a  |4 $.@A.....> d..|
000000b0  d2 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001a0  00 ff fb 60 c4 00 00 01  d0 19 46 14 91 00 2a b7  |...`......F...*.|

Header, zeroes, "Xing". This decodes nicely to silence if not parsed as
metadata. Now, the user as a file that apparently was encoded by Lame,
too, but also features some extra bytes of … something in the
interspace:

[skipped ID3v2]
00012d90  00 00 00 00 00 00 00 00  00 00 00 ff fb 94 44 04  |..............D.|
00012da0  00 04 f9 5f 00 00 00 00  00 00 00 00 00 00 00 00  |..._............|
00012db0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 58  |...............X|
00012dc0  69 6e 67 00 00 00 0f 00  02 1d 53 05 9e 1d c0 00  |ing.......S.....|
00012dd0  03 05 08 0a 0d 0f 12 15  17 1a 1d 1f 22 25 27 2a  |............"%'*|
00012de0  2c 2f 32 34 37 3a 3c 3f  41 44 47 49 4c 4e 51 53  |,/247:<?ADGILNQS|
00012df0  56 58 5b 5d 60 63 65 68  6a 6d 6f 72 74 77 7a 7c  |VX[]`cehjmortwz||
00012e00  7f 81 84 86 89 8b 8e 90  93 95 98 9a 9d a0 a2 a5  |................|
00012e10  a7 aa ac af b1 b4 b6 b9  bb be c0 c3 c5 c8 cb cd  |................|
00012e20  d0 d2 d5 d7 da dc df e2  e4 e7 e9 ec ee f1 f3 f6  |................|
00012e30  f9 fb fd 00 00 00 64 4c  41 4d 45 33 2e 39 38 72  |......dLAME3.98r|
00012e40  04 c3 00 00 00 00 00 00  00 00 34 20 24 05 40 8d  |..........4 $.@.|
00012e50  00 01 f4 05 9e 1d c0 36  e0 66 c7 00 00 00 00 00  |.......6.f......|
00012e60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00012f10  00 00 00 00 00 00 00 00  00 00 00 ff fb c4 44 21  |..............D!|

My code in mpg123 rejects to parse that VBR tag because it specifically
looks for a silent frame with all zeroes after the header (and crc)
before the "Xing".

I now wonder if I am correct in insisting on that or not. What do you say?

When treating that frame as MPEG data, mpg123 gets into trouble on the
following frame (the first proper frame of the track) with.

[libmpg123.c:834] debug: decoding
[layer3.c:1191] debug: Can't rewind stream by 123 bits!

[layer3.c:1978] error: dequantization failed!

So, it's confused by decoder state introduced by that funny first
frame. All seems fine if I make mpg123 parse that frame instad.

Hints? Any reason there should be something else than zeroes between
header/crc an "Xing" or "Info"? So far, this is the one and only file
reported with that. Other decoders than mpg123 parse the frame without
complaint, though.


Alrighty then,

Thomas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Info/Xing tag: Should a decoder insist on zeroes after header?

Thomas Orgis
Am Thu, 26 Feb 2015 09:37:21 +0100
schrieb Thomas Orgis <[hidden email]>:

> Hints? Any reason there should be something else than zeroes between
> header/crc an "Xing" or "Info"? So far, this is the one and only file
> reported with that. Other decoders than mpg123 parse the frame without
> complaint, though.

No takers? Is there someone specific I should talk to regarding the
design of the Xing/Info frame?


Alrighty then,

Thomas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Info/Xing tag: Should a decoder insist on zeroes after header?

Robert Hegemann
Hello Thomas!

Am 10.03.2015, 08:10 Uhr, schrieb Thomas Orgis <[hidden email]>:

> Am Thu, 26 Feb 2015 09:37:21 +0100
> schrieb Thomas Orgis <[hidden email]>:
>
>> Hints? Any reason there should be something else than zeroes between
>> header/crc an "Xing" or "Info"? So far, this is the one and only file
>> reported with that. Other decoders than mpg123 parse the frame without
>> complaint, though.
>
> No takers? Is there someonHee specific I should talk to regarding the
> design of the Xing/Info frame?

To my own understanding Xing/Info tags are only valid in silent frames.
If the user really was able to let LAME write it into a none-silent frame,
I would be curious to know how he did it, cos that would be a bug in LAME.

The problem with decoding the following frame was due to the back pointer
pointing into the Xing/Info data?

>
> Alrighty then,
>
> Thomas

Ciao Robert

--
There is an art, it says, or rather, a knack to flying. The knack lies in  
learning how to throw yourself at the ground and miss. Pick a nice day,  
[The Hitchhiker's Guide to the Galaxy] suggests, and try it.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Info/Xing tag: Should a decoder insist on zeroes after header?

Thomas Orgis
Am Tue, 10 Mar 2015 10:00:16 +0100
schrieb robert <[hidden email]>:

> Hello Thomas!

A human! Thank you;-)

> To my own understanding Xing/Info tags are only valid in silent frames.
> If the user really was able to let LAME write it into a none-silent frame,
> I would be curious to know how he did it, cos that would be a bug in LAME.

I am wondering about how this comes to be, as I didn't encounter this
before. Do you define a silent frame as "all zeroes between header/crc
and Xing/Info data"? As, technically, the first frame does decode to
silence, but contains funny data that confuses the decoder.

> The problem with decoding the following frame was due to the back pointer
> pointing into the Xing/Info data?

I didn't look closer into how exactly this frame is interpreted (I'm not
fluent in MPEG by just looking at the hex dump, I assumed you folks
are;-), but yes, I assume that. Everything is fine when the frame after
the Xing frame is decoded as first in stream.

At least you confirm that it is not expected that LAME wrote the frame
like that, right? So perhaps it's really just garbage. So, I'd think
the decoder is right in being suspicious and refusing to use the frame.
But the user says "Everything works when you use that info, why do you
want to cripple the features (gapless decoding, fast seeking) of the
decoder?"

Well, I guess one has to look at that data to see if it might be some
information added by a third-party tool. But I got only one report
about a single file so far …


Alrighty then,

Thomas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Info/Xing tag: Should a decoder insist on zeroes after header?

Robert Hegemann
Am 11.03.2015, 10:20 Uhr, schrieb Thomas Orgis <[hidden email]>:

> At least you confirm that it is not expected that LAME wrote the frame
> like that, right? So perhaps it's really just garbage. So, I'd think
> the decoder is right in being suspicious and refusing to use the frame.
> But the user says "Everything works when you use that info, why do you
> want to cripple the features (gapless decoding, fast seeking) of the
> decoder?"

I can't rule out that LAME isn't at fault there. Maybe there is/was a
bug in LAME, but it isn't normal behaviour.

> Well, I guess one has to look at that data to see if it might be some
> information added by a third-party tool. But I got only one report
> about a single file so far …

I have no experience with tools that fix missing LAME/Info headers.
Eventually there is some tool out there putting it just into the
first frames ancillary data section?

Well, if you got that file, put it aside and ignore it for now.

> Alrighty then,
>
> Thomas

Ciao Robert

--
There is an art, it says, or rather, a knack to flying. The knack lies in  
learning how to throw yourself at the ground and miss. Pick a nice day,  
[The Hitchhiker's Guide to the Galaxy] suggests, and try it.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev