Xing/Lame header: frame count and stream size including VBR header?

Hi!

I have written (yet another, of course better) MP3 analysis/validation tool
and found that different tools and encoders do not agree on the number of
bytes and/or frames stored in the Xing/Lame VBR header.  The most
common "mistake" as I understand is to include this VBR information frame
within the statistics.  AFAIK there are no official specs for the VBR tag,
and all docs I know contain ambiguous information about this problem, but I
think it is most sensible to exclude the Xing frame from the numbers, since
the purpose of the statistics is to be able to compute the running time and
average bitrate of the file, isn't it?

Specifically, I noticed that files I encoded recently with lame 3.97 have the
correct number of (audio data-only) MPA frames set, but the total byte count
includes the Xing tag.

Is lame's behaviour in this respect documented anywhere (ideally for specific
versions)?

Is there a rationale for including the Xing tag in the byte count, but not in
the frame count?

Do you disagree with my own opinion that the Xing tag should be excluded from
both values?

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder

On Donnerstag 27 Dezember 2007, Hans Meine wrote:

> [...] I noticed that files I encoded recently with lame 3.97 have
> the correct number of (audio data-only) MPA frames set, but the total byte
> count includes the Xing tag [itself].
>
> Is lame's behaviour in this respect documented anywhere (ideally for
> specific versions)?
>
> Is there a rationale for including the Xing tag in the byte count, but not
> in the frame count?
>
> Do you disagree with my own opinion that the Xing tag should be excluded
> from both values?

Now that I hope most people have returned from their christmas/new year
holidays, does noone have an opinion on this?

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder

[Bill Kincaid]

For what it's worth, in iTunes we do it exactly as LAME does.  This  
is probably for historical reasons- I can't think of a strong reason  
either way.  The whole XING VBR descriptor was an ad-hoc solution,  
minimally documented.  Useful to be sure but not meticulously  
engineered.

-Bill


On Jan 12, 2008, at 10:03 PM, Hans Meine wrote:

> On Donnerstag 27 Dezember 2007, Hans Meine wrote:
>> [...] I noticed that files I encoded recently with lame 3.97 have
>> the correct number of (audio data-only) MPA frames set, but the  
>> total byte
>> count includes the Xing tag [itself].
>>
>> Is lame's behaviour in this respect documented anywhere (ideally for
>> specific versions)?
>>
>> Is there a rationale for including the Xing tag in the byte count,  
>> but not
>> in the frame count?
>>
>> Do you disagree with my own opinion that the Xing tag should be  
>> excluded
>> from both values?
>
> Now that I hope most people have returned from their christmas/new  
> year
> holidays, does noone have an opinion on this?
>
> Ciao, /  /                                                    .o.
>      /--/                                                     ..o
>     /  / ANS                                                  ooo
> _______________________________________________
> mp3encoder mailing list
> [hidden email]
> https://minnie.tuhs.org/mailman/listinfo/mp3encoder

_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder