WMA lossless adds 15 samples in .92b5 Options

[reardon]

I am converting some WMA lossless to FLAC/APE. In each case, the resulting FLAC or APE or even WAV file contains 15 samples too many.

[foobar 0.92 beta 5]

Update: dbPoweramp has the same problem. This is likely an issue with WM runtime? Has anyone successfully gotten proper sample counts? I am using WMP11, or rather whatever runtime comes with WMP11.


+Reardon

This post has been edited by reardon: Jun 6 2006, 13:21

[kode54]

The header indicates the file length in nanoseconds, but is usually only accurate to 10ms, rounded down. Is that 15 samples more than you originally encoded, or 15 samples more than the file info dialog reports?

[reardon]

The header indicates the file length in nanoseconds, but is usually only accurate to 10ms, rounded down. Is that 15 samples more than you originally encoded, or 15 samples more than the file info dialog reports?

File info dialog is reporting 15 samples longer, regardless of the original length.

[Peter]

Automated tests of WMA decoder already pointed this problem before, but it's clearly on MS side and there's not much we can do about it, unless I'm missing something obvious.
Seeking and length reporting is clearly inaccurate for WMA including WMA lossless; only thing I can do is to recommend everyone to stay away from this format as far as archiving use goes.

[b50]

Which automated test are you referring to?

I did a simple test. I ripped a CD track to WAV and WMA lossless. Then decoded WMA lossless to WAV. The two WAV files have exactly the same length.

And what do you mean by 'clearly inacuurate'? Do you have any samples?

[foosion]

Which automated test are you referring to?

Tests made using an as of yet unreleased decoder verification component.

And what do you mean by 'clearly inacuurate'? Do you have any samples?

Look at the original post and the first replies.

[Peter]

According to my tests (using WMP10 runtime that came with winxp 64bit), WMA "lossless" was decodable back to original length, but it was impossible to query sample-accurate length without full decode, or seek accurately. Original poster reported that decoding is inaccurate too; I guess it might be a new problem introduced in WMP11 runtime.
Even on my configuration, WMA "lossless" is basically lossy when decoded over cuesheet, unless I implement extremely-inefficient bruteforce seek workaround, which I don't plan to as I think I've wasted enough of my time on researching MS WMA runtime issues already.