Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Xing header treatment (incorrect number of samples reported) (Read 2056 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Xing header treatment (incorrect number of samples reported)

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?
[attachment=7146:sample.zip]

Xing header treatment (incorrect number of samples reported)

Reply #1 –
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.

[attachment=7148:sample2.zip]

Xing header treatment (incorrect number of samples reported)

Reply #2 –
foobar2000 always subtracts the decoder delay of 529 samples.

Xing header treatment (incorrect number of samples reported)

Reply #3 –
Quote from: kode54 on
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.
 

Xing header treatment (incorrect number of samples reported)

Reply #4 –
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).

Xing header treatment (incorrect number of samples reported)

Reply #5 –
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 [a href='index.php?showtopic=95662']twice[/a], to no avail.

Xing header treatment (incorrect number of samples reported)

Reply #6 –
Quote from: mjb2006 on
I have recently reported this issue [a href='index.php?showtopic=95662']twice[/a], to no avail.

Oh, I didn't read your post, thanks.
I should have checked the forum before repeating already posted issue...

Xing header treatment (incorrect number of samples reported)

Reply #7 –
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).