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

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

> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev