IPB

Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.


See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
Xing header treatment (incorrect number of samples reported)
nu774
post Oct 12 2012, 12:02
Post #1





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



fb2k seems to report somewhat mysterious number of samples for MP3 files with Xing header, when the Xing header doesn't have any trailing (LAME header or something).

In the attached file, "LAME.mp3" is encoded by the LAME encoder, and libav.mp3 is just a remuxed version using avconv program of libav project.
The latter one lacks LAME header, but has a Xing header. In the Xing header, it correctly says total number of frames is 422, which becomes to 422*1152=486144 samples.

However, fb2k (v1.1.15) shows "485615 samples" on the property dialog, which is not even multiples of 1152.
Encoder-delay or something is assumed here?
Attached File  sample.zip ( 395.08K ) Number of downloads: 32
Go to the top of the page
+Quote Post
nu774
post Oct 14 2012, 16:26
Post #2





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



BTW, if I edit only a single byte just after the Xing header in MP3 file, fb2k seems to report expected number of samples.

In the attached file, libav.mod.mp3 is the modified file.
libav.txt and libav.mod.txt are binary hex dumps of each MP3, where byte at 000000C2 is modified.
Hope this helps.

Attached File  sample2.zip ( 593.95K ) Number of downloads: 26


This post has been edited by nu774: Oct 14 2012, 16:26
Go to the top of the page
+Quote Post
kode54
post Oct 14 2012, 21:48
Post #3





Group: Admin
Posts: 4695
Joined: 15-December 02
Member No.: 4082



foobar2000 always subtracts the decoder delay of 529 samples.
Go to the top of the page
+Quote Post
nu774
post Oct 15 2012, 02:22
Post #4





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (kode54 @ Oct 15 2012, 05:48) *
foobar2000 always subtracts the decoder delay of 529 samples.

Thanks, that's explains where difference of 529 comes from;
But then, why it's different on the modified case (libav.mod.mp3)?
Edited position is 6th byte after the Xing header, where encoder name or version goes in case of LAME or iTunes.
I modified 0x00 to 0x41( ascii 'A') on the attached example, but actually any ascii printable character seems to bring the same result.
Go to the top of the page
+Quote Post
nu774
post Oct 15 2012, 04:31
Post #5





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



I looked at it further, and it turned out that difference of mod version only affects the property dialog.
When decoded, the result including total number of samples is the same as unmodified version (so, decoder delay is subtracted. I looked at the resulting waveform and confirmed zero-padding at the beginning due to decoder delay was removed).
Go to the top of the page
+Quote Post
mjb2006
post Oct 15 2012, 13:26
Post #6





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Probably fb2k thinks a non-null encoder string indicates a LAME tag is present (seems reasonable), so it tries to get info from it. Encoder delay and padding values therein are just zeroes in your test file, so estimated duration has nothing trimmed. Estimated duration should be the same as the unmodified version, of course, but for unknown reasons, foobar2000 doesn't subtract the 529 samples of decoder delay in this situation. This is the same result as if the file had no VBR header frame at all.

The incorrect duration estimate doesn't just affect the properties dialog; the file will also fail the Verify Integrity check (select in playlist, right-click, > Utilities > Verify Integrity, assuming you enabled it when installing fb2k).

I have recently reported this issue twice, to no avail.

This post has been edited by mjb2006: Oct 15 2012, 13:28
Go to the top of the page
+Quote Post
nu774
post Oct 15 2012, 16:36
Post #7





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (mjb2006 @ Oct 15 2012, 21:26) *
I have recently reported this issue twice, to no avail.

Oh, I didn't read your post, thanks.
I should have checked the forum before repeating already posted issue...
Go to the top of the page
+Quote Post
mjb2006
post Oct 15 2012, 23:14
Post #8





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



No need to apologize; your experimentation is valuable because it reveals that there is another condition under which the decoder delay isn't subtracted from the duration estimate. I thought it only happened when there's no Xing/VBR info frame at all, but apparently it also happens when the frame is present and declares less than 529 samples of padding.

Technically, though, I think these cases should be handled differently. Yes, the duration estimate should always match what you're going to get when decoding. But the way they're decoded could be improved. When there's less than 529 samples of padding declared—or, IMHO, no padding declared at all—I feel there should be some effort made to reach the last samples. I would simply feed an extra frame of silence to the decoder and then trim that frame's-worth of samples from the end, plus however many samples of padding was declared. I believe this would allow proper playback of MP3s made "gapless" the old-fashioned way (e.g. via mp3DirectCut, or by encoding with LAME's abandoned --nogap option).
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: 29th December 2014 - 11:26