Re: [mpg123-devel] Monitor and cancel stream scanning

[Olivier G. <li...@sa...>]

On 09/14/2010 08:07 PM, Thomas Orgis wrote:
> Am Tue, 14 Sep 2010 18:49:31 +0200
> schrieb Olivier Guilyardi <li...@sa...>: 
> 
>> I have noticed that mpg123_length() reports an accurate length in samples when
>> it's read from the Xing header or so.
>>
>> If such metadata is present, I'm ok to rely on it. Otherwise I would fallback on
>> scanning.
>>
>> How can I know whether mpg123 found the length that it reports by parsing the
>> metadata header, or if it's just an estimation based on the filesize?
> 
> Uh. Eh. You don't. You only know what you got after scanning. That also covers damaged files where there's some junk in between. Everything that mpg123_scan finds will produce the determined amount of samples (if the found frames are still bad, they result in silence, but the duration matches).
> MPEG audio in general is decentralized by design... those headers trying to give you information like the total length of the file also end up in internet streams of individual tracks concatenated together... so they are always some kind of wannabe helpful hint, but never the whole truth.

Well, okay, got that..

> When you need the exact sample count, you have to scan. If you need just some approximate length info for humans, you don't have to (and you could update the info by calling mpg123_length() once in a while; estimates of VBR files might get better).

Well, I'm not sure about what I can do with mpg123_length's estimation. I was
trying to implement some kind of clever system, where scanning is done
on-demand, the approximated length updated progressively, etc...

But, I have this 48Khz 5:20s VBR file encoded with lame -V2. Without scanning,
mpg123 reports 15360000 frames, which is exact and sample accurate.

But if I use MPG123_IGNORE_STREAMLENGTH to simulate missing metadata, I get
34826735 frames. That's 127% error :( I really can't display such bogus length
when opening the file, even if it gets updated after progressive scanning..

So, my question was about determining whether mpg123 did find some length in the
metadata or not, since the approximation accuracy apparently varies a lot
according to that. And if the metadata information is present but very bogus,
then the culprit is the mp3 file, not my app.

> 
>> Is the length value read from the metadata always sample accurate, or may it be
>> converted/approximated from a value in seconds read from, say, an ID3 duration tag?
> 
> Length values from headers should always dealt with as approximate. One reason is already that decoders behave differently regarding encoder/decoder delay (mpg123 cuts that out). Some give and take some few hundret / thousands samples at least.

Okay, good tip. I didn't think about such decoder/encoder misunderstanding about
precise length.

--
  Olivier