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: A .wma that decodes inconsistently (Read 7275 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A .wma that decodes inconsistently

Link to bootleg recording: https://www.sendspace.com/file/j3kml5 . As encrypted .7z in case Sendspace would otherwise index content; passphrase: hydrogenaudio Mods: feel free to remove link if appropriate.


So I have .wma file that when foo_bitcompare'd to a copy of itself, shows differences in typically 2 samples; occasionally 4, occasionally 0. Tested with Windows 7 and 10. Originally I thought that tagging or not made the difference, but you can just make a copy of the file and run the comparison.

According to Peter, fb2k uses only Windows' decoding component, so there is the blame.  It should not happen even if the bitstream is corrupted (or was written to an obsolete spec version) - or whether there is any utility that can even test integrity.
Is there any such test utility? ( ffmpeg decoding throws a lot of errors, but ffmpeg and wma is fishy matter anyway. Try to remux it and get a seventy-percent overhead ...)


... seriously: Has Microsoft actually screwed up every WMA there ever was? Windows 10 builds not supporting WMAL playback - apparently affecting WMA Pro as well; and then in https://hydrogenaud.io/index.php?topic=92847.25 , read spoon on how bugs went ignored for years, and saratoga on how Microsoft spent ten years not being able to decode WMA Voice correctly ...
Well in the very least: when MS discontinued DRM'ed WMA, they did offer MP3 rather than DRM-free WMA.

Re: A .wma that decodes inconsistently

Reply #1 –
Maybe because the file is showing a lot of clipping ? Mainly on left channel.

Re: A .wma that decodes inconsistently

Reply #2 –
Yes, exist a component for test WMA audio files and others, but I tested WMA lossless and almost all are with problems from number of samples reported by the file is less than the true. I suppose that WMA is not true gapless as Vorbis or Opus. But I never has had problems decoding, I have problems encoding some of the last samples with no silent.

Here the component for FB2K for test files: File Integrity Verifier

Re: A .wma that decodes inconsistently

Reply #3 –
No, foo_verifier cannot help:  fb2k only uses Windows' internal WMA decoder, and as long as that happily delivers audio - correct or incorrect audio - without screaming, foo_verifier cannot know.  Read Peter's warning that with most formats, its accuracy is limited to detecting errors that abort the decoding process.

Quote from: gagorial on
almost all are with problems from number of samples reported by the file is less than the true
The ASF container can apparently only report to the nearest millisecond.  There was a recent thread here: https://hydrogenaud.io/index.php?topic=121732 . A player that knows, will retrieve the number of samples from the stream rather than from the file - whenever it needs to get it correct, at least.
So it is the container that sucks - this time. The container is not the only reason that WMA sucks.

As for Opus gaplessness ... https://hydrogenaud.io/index.php?topic=116605.0 .

Re: A .wma that decodes inconsistently

Reply #4 –
Sorry, but I don't know :-( how help you.

And yes I think the same about WMA format. WMA is awful.

Re: A .wma that decodes inconsistently

Reply #5 –
Wow, Cog wasn't decoding this correctly at all, stopping every time that FFmpeg threw a warning. FYI, from the first 4 minutes of the file alone:

Code: [Select]
[wmav2 @ 0x135f23410] overflow (1865 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1913 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1870 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1865 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (119 > 116) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1869 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1871 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1877 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1869 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (117 > 116) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (476 > 466) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1866 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] overflow (1870 > 1864) in spectral RLE, ignoring
[wmav2 @ 0x135f23410] frame_len overflow

Looks like Windows Media did some funny things with this file. I'd be surprised if anything decoded it consistently.

I have amended Cog to be able to play it at all, it should play to completion now. The first version to play it at all without interruption would be 2110-g90ed0230.

Edit: I ran decode outputs to WAV using FFmpeg. At least it manages to produce consistent output from the same file twice in a row.

Edit 2: Gee, thanks! There's a super deafening glitch at 33:50!

Re: A .wma that decodes inconsistently

Reply #6 –
So the file is gone from Sendspace by now, but if anyone else needs it ...

Quote from: kode54 on
Edit: I ran decode outputs to WAV using FFmpeg. At least it manages to produce consistent output from the same file twice in a row.
My ffmpeg (5.0 for Windows) drops more than two minutes from the file, so ... consistent, but unambiguously wrong.
If there is any sanity to what ffmpeg drops, the most troublesome blocks would be out.

(Length according to foo_verifier: Warning: Reported length is inaccurate : 1:24:29.568000 vs 1:24:29.464558 decoded)

Quote from: kode54 on
Edit 2: Gee, thanks! There's a super deafening glitch at 33:50!
FWIW, foobar2000 RG-scans to peak of 1.002219, that isn't super anything - and foo_bitcompare differences were too low to make for anything glitchy.

Re: A .wma that decodes inconsistently

Reply #7 –
I don't know what it is about Microsoft, but they've always had this uncanny ability to just make absolute trash, and it's always a particularly "Microsofty" flavour of trash, you can instantly recognise it. (Nothing embodies this Microsofty trashiness in a more perfect and quintessential manner than Microsoft Songsmith.) WMA started off as Microsoft's trashy way to cash in on the popularity of MP3 and it started off with a properly trashy bang - with Microsoft claiming it provides CD Audio level quality at 64 kbps. It really amuses me that, decades later, the trashiness just keeps emerging.

Re: A .wma that decodes inconsistently

Reply #8 –
Can you share file to me? Perhaps you checked that older versions of ffmpeg worked ok? Because some devs tend to push patches that check to "fix" for strict overflows that may give this wrong decoding.

Re: A .wma that decodes inconsistently

Reply #9 –
Edit:
managed to delete the bin with the good upload instead of the one I made a mess out of. Will edit in some minutes when I get uploaded a new.

Quote from: Porcus on
As encrypted .7z in case Sendspace would otherwise index content; passphrase: hydrogenaudio

Same now.
I got the word that Sendspace is annoying to those who don't have as good an ad-killer ... dunno if true, but I tried another upload bin.

Re: A .wma that decodes inconsistently

Reply #10 –
Here!

There are two files. One is a backup I have never altered with tags or anything (except the filename). Setting 7-zip dictionary size above file size, and they are compressed as one.

Re: A .wma that decodes inconsistently

Reply #11 –
Quote from: Porcus on
Quote from: kode54 on
Edit 2: Gee, thanks! There's a super deafening glitch at 33:50!
FWIW, foobar2000 RG-scans to peak of 1.002219, that isn't super anything - and foo_bitcompare differences were too low to make for anything glitchy.

Goody for the system codecs, but FFmpeg handles it a little bit differently:

Code: [Select]
Corrupted file - peak too high (38655.2812500)

Screen shots of the two glitches:

X

X

Yes, these did manage to defeat my player being set to 25% volume, and the headphone output being set to ~40% volume.

Re: A .wma that decodes inconsistently

Reply #12 –
The issue with WMA is that it was never really standardized.  Even MS's own "specification" was just their decoder source code, which changed over time as bugs were fixed and versions incremented, so compatibility was more aspirational than actual.  There is probably a decoder somewhere that works correctly with all valid WMA files, but it isn't necessarily the one shipping in Windows (or ffmpeg).

As for ffmpeg vs Windows, back 10 years ago when I was working on the fixed point wma decoder for rockbox, people sent me lots of files that didn't decode identically in Windows as they did in ffmpeg (my standard test with the fixed point decoder would glitch).  I think ffmpeg has improved some since then, but wma is kind of a mess.

Re: A .wma that decodes inconsistently

Reply #13 –
This is FFmpeg 5.0.

Okay, for the stats, from that file:

First major corruption is at packet 114166, for two 768 sample packets. The other one is at 256153, and takes four packets to recover to a reasonable signal.

Re: A .wma that decodes inconsistently

Reply #14 –
Since nothing outside of Windows can decode this properly, clearly the correct answer is to transcode it to something universal, using Windows as the converter. I'll take my chances with the 64kbps stereo MP3 I found on some jazz web site.

Or I can stick with the WMA. Windows 11 for ARM manages to decode it consistently, even if the length is different than the reported length by less than a second. Peak under 1.0.

Re: A .wma that decodes inconsistently

Reply #15 –
Quote from: saratoga on
There is probably a decoder somewhere that works correctly with all valid WMA files, but it isn't necessarily the one shipping in Windows (or ffmpeg).
More precisely:
"For each valid WMA file, there is probably a decoder that handles it correctly."
? (Meaning, of course not the same for each file.)

I think not! The point about this posting is that Windows (7 and 10) got WMA decoders that do not reset between tracks, so upon decoding two in succession, track#2 depends upon the content of track#1.
Edit: Oh wait, the file decodes consistent on Windows XP. Since the WMA was generated 2009, the XP version might be The Truth then? Especially if nobody has ever bothered to encode WMA since XP? ;-) 

I decoded the two-in-succession to 32-bit float on Windows 7 and on Windows 10 and got four different MD5's, starting with (Win7:) 5FE1126F, 6EDCE364, (Win10:) A4E98B8A0, E4F9D4AD.
On XP, decoding appears consistent. D4A1E42D44ACE82AB1CFB010A5E135CE 
And XP decodes to longer: 223 565 824 samples vs 223 563 387.

Quote from: kode54 on
Windows 11 for ARM manages to decode it consistently, even if the length is different than the reported length by less than a second. Peak under 1.0.
I don't have neither Windows 11 nor ARM, so I'd be surprised if the MD5 matches mine. (foo_verifier on Windows 7 and Windows 10 agree that they are 0.999969, the 1.02 was RG with true peak scan to detect extreme artifacts like you mentioned.)


Quote from: kode54 on
I'll take my chances with the 64kbps stereo MP3 I found on some jazz web site.
music_1_1098.mp3 I presume. I see now that Google has gotten that site up high.
It is the guy who offered the WMA in the first place. Site later redesigned and format replaced with something more sensible - it isn't so much about extreme fidelity for nth generation tape copies of bootleg recordings or FM broadcasts.

Treat yourself to the Swedish radio's 1992 broadcast of the Terje Rypdal trio.

Re: A .wma that decodes inconsistently

Reply #16 –
Quote from: Porcus on
Especially if nobody has ever bothered to encode WMA since XP? ;-)

You jest, but I honestly think this is more likely than you'd think.

I still* get indescribably upset whenever I see a random media player (in cars and stereos) which supports WMA but not OGG.

(* - Actually, not sure how well the word "still" fits here, because - logically - the more time passes, the more upset I get.)