[SOLVED] 64-bit wma2wav.exe crashing on Windows 8.1

[filler56789]

Instead of grave-digging the thread https://forum.doom9.org/showthread.php?t=140273 ,
I decided to open this new one.

As the title says, the last time I had used the 64-bit wma2wav.exe, I had a Windows 7 machine, and IF I remember correctly :) , the program worked normally...

but this morning, on a Windows 8.1 desktop, the same binary refused working. :confused:

OTOH, the 32-bit edition of wma2wav works fine on Windows 8.1, so I replaced the 64-bit executable with the XP-friendly one.

QUESTION: has this problem happened to the users of Windows 10 and 11 as well? Or it's only me? :confused:

[lvqcl]

32-bit exe is packed with UPX, and 64-bit one is packed with MPRESS (?). So apparently this packer is not fully compatible with Windows newer than 7.

[filler56789]

32-bit exe is packed with UPX, and 64-bit one is packed with MPRESS (?). So apparently this packer is not fully compatible with Windows newer than 7.

Thanks for the insight. :goodpost:

According to the page https://www.autohotkey.com/mpress/mpress_web.htm,
yes you are right. :(

Operating Systems: Windows 9x/NT/2000/XP/2003/Vista/2008/Windows7, MAC-OS 10.3/10.4

I hope Lord_Mulder will chime in soon :-|

[GeoffreyA]

On Windows 10 and a Ryzen CPU, I gave wma2wav a try and the 64-bit binary doesn't work; the 32-bit one does. I also looked to see if MPRESS can decompress an executable, as UPX, but could not find such an option.

Considering that the wma2wav binaries are from 2011, though, I would advise using a more updated tool. FFmpeg can decode WMA files.

ffmpeg -i INPUT.wma OUTPUT.wav

[tormento]

I also looked to see if MPRESS can decompress an executable, as UPX, but could not find such an option
Actually, just google mpress decompress.

There are utilities and tutorials.

[filler56789]

Considering that the wma2wav binaries are from 2011, though, I would advise using a more updated tool. FFmpeg can decode WMA files.

In 2011, only wma2wav, Winamp and Avisynth's BassAudio were able to decode correctly borked WMA streams generated through video or screen capture.
I really don't know if the ffmpeg source-code has been updated accordingly :-|

[GeoffreyA]

Actually, just google mpress decompress.

There are utilities and tutorials.

Thanks, tormento.

In 2011, only wma2wav, Winamp and Avisynth's BassAudio were able to decode correctly borked WMA streams generated through video or screen capture.
I really don't know if the ffmpeg source-code has been updated accordingly :-|

I see. There shouldn't be any harm using the 32-bit binary: its results should be the same as the 64-bit one, hopefully. One could try, as tormento suggested, decompressing the packed executable, but it seems it would be simpler to compile wma2wav's source code. There is a Visual Studio solution file.

[tebasuna51]

Also don't work in W10.

BTW ffmpeg-64 is 2.3 times faster decoding .wma than wma2wav-32.

In 2011, only wma2wav, Winamp and Avisynth's BassAudio were able to decode correctly borked WMA streams generated through video or screen capture.
I really don't know if the ffmpeg source-code has been updated accordingly :-|

But I don't if can decode that streams.

[filler56789]

Very well, I "grave-digged" one of those popular borked WMV video recordings,
and then tested both wma2wav and ffmpeg 7.0.2.

Final results: the .wav file generated by wma2wav = 41 minutes + 4 seconds,
whereas the .wav file generated by ffmpeg = 40 minutes + 57 seconds.

Below is the example of what wma2wav can do but ffmpeg is unable to do:

Opening output file... OK

Inconsistent timestamps: Expected 216.27700000 next, but got 217.00000000.
There is a "gap" of 0.72300000 seconds, padding 138816 zero bytes!
Inconsistent timestamps: Expected 502.86600000 next, but got 503.00000000.
There is a "gap" of 0.13400000 seconds, padding 25728 zero bytes!
Inconsistent timestamps: Expected 551.61300000 next, but got 552.15100000.
There is a "gap" of 0.53800000 seconds, padding 103296 zero bytes!
Inconsistent timestamps: Expected 770.11900000 next, but got 771.00000000.
There is a "gap" of 0.88100000 seconds, padding 169152 zero bytes!
Inconsistent timestamps: Expected 779.61800000 next, but got 779.98300000.
There is a "gap" of 0.36500000 seconds, padding 70080 zero bytes!
Inconsistent timestamps: Expected 1131.30000000 next, but got 1132.00000000.
There is a "gap" of 0.70000000 seconds, padding 134400 zero bytes!
Inconsistent timestamps: Expected 1138.37500000 next, but got 1138.78300000.
There is a "gap" of 0.40800000 seconds, padding 78336 zero bytes!
Inconsistent timestamps: Expected 1158.13500000 next, but got 1158.53800000.
There is a "gap" of 0.40300000 seconds, padding 77376 zero bytes!
Inconsistent timestamps: Expected 1454.43100000 next, but got 1455.00000000.
There is a "gap" of 0.56900000 seconds, padding 109248 zero bytes!
Inconsistent timestamps: Expected 1460.24700000 next, but got 1460.63100000.
There is a "gap" of 0.38400000 seconds, padding 73728 zero bytes!
Inconsistent timestamps: Expected 1462.93500000 next, but got 1463.31900000.
There is a "gap" of 0.38400000 seconds, padding 73728 zero bytes!
Inconsistent timestamps: Expected 1920.62000000 next, but got 1921.00000000.
There is a "gap" of 0.38000000 seconds, padding 72960 zero bytes!
Inconsistent timestamps: Expected 1951.37800000 next, but got 1951.70100000.
There is a "gap" of 0.32300000 seconds, padding 62016 zero bytes!
Inconsistent timestamps: Expected 1954.15100000 next, but got 1954.62000000.
There is a "gap" of 0.46900000 seconds, padding 90048 zero bytes!
Inconsistent timestamps: Expected 2217.83100000 next, but got 2218.00000000.
There is a "gap" of 0.16900000 seconds, padding 32448 zero bytes!
Inconsistent timestamps: Expected 2226.53300000 next, but got 2226.87400000.
There is a "gap" of 0.34100000 seconds, padding 65472 zero bytes!
Inconsistent timestamps: Expected 2246.28700000 next, but got 2246.73800000.
There is a "gap" of 0.45100000 seconds, padding 86592 zero bytes!
[100.0%] 41:04.2 of 41:04.2 completed, please wait...
Warning: Sync correction inserted 1463424 zero bytes, skipped 0 bytes.

All done.

[filler56789]

P.S.: Just tested mpv right now.
Even though it does not lose the audio-video synchronization,
the error message it displayed shows how much the *nix-centric programmers are still living in the last decade of the 20th century :D

(+) Video --vid=1 (wmv3 960x540 29.970fps)
(+) Audio --aid=1 --alang=kor (wmav2 2ch 48000Hz)

<SNIP>

[vo/gpu/d3d11] Failed to query swap chain's output information
AO: [wasapi] 48000Hz stereo 2ch float
VO: [gpu] 960x540 yuv420p

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).
Consider trying `--profile=fast` and/or `--hwdec=auto-safe` as they may help.

Invalid audio PTS: 1954.194667 -> 1954.578000
Invalid audio PTS: 2217.831333 -> 2218.000000
Invalid audio PTS: 2226.576000 -> 2226.832000
[input] No key binding found for key 'Alt+F4'.
(Paused) AV: 00:37:19 / 00:41:04 (91%) A-V: 0.000 ct: 0.339
Exiting... (Quit)

[GeoffreyA]

I believe that wma2wav uses Windows' WMA runtime, whereas FFmpeg has a native decoder. Therefore, it makes sense that wma2wav, relying on the code in Windows, is doing a better job than FFmpeg.

[filler56789]

I believe that wma2wav uses Windows' WMA runtime, whereas FFmpeg has a native decoder. Therefore, it makes sense that wma2wav, relying on the code in Windows, is doing a better job than FFmpeg.

ffmpeg simply ignores the audio timestamps in the ASF container, this is the reason why it fails when it meets WMA streams that contain gaps or/and overlaps.

[GeoffreyA]

We should consider submitting this to the FFmpeg bug list. If it's happening with WMA and ASF, perhaps with other formats too.

[tebasuna51]

Yes this can happen with other formats, but I think than is not a bug in ffmpeg decoders, is a bug in software than create that audio with timestamps inconsistent with audio duration.

With video timestamps we say how many time a fix video frame is show in the screen, but audio frames have a fix duration (samples * samplerate) and say a different duration with timestamps don't have sense at all.

The "correct" behaviour:
...
Inconsistent timestamps: Expected 1131.30000000 next, but got 1132.00000000.
There is a "gap" of 0.70000000 seconds, padding 134400 zero bytes!
...
Implies fill with 0.7 seconds of silence, if that happen inside a strong sound can produce audible clicks.

To restore the sync of that sound we need a list of gaps and edit the decoded track to insert the silences (or repeat background noise) in near points without impact.

[filler56789]

It's not a bug, it's a "feature" :p of the stupid Microsoft container.
The acronym A.S.F. originally meant «Active :rolleyes: STREAMING Format».
So its goal was to deal "conveniently" :rolleyes: with the internet of the 90s, that is to say,
lots of dropped video frames (and lost audio samples). :-/

[john33]

And here it is: https://www.rarewares.org/files/others/wma2wav-2011-10-01.zip
Briefly tested on win 10 and win 11 x64. I'll place a proper entry on Rarewares later with the slightly amended source code.

Edit: Rarewares updated,

[filler56789]

And here it is: https://www.rarewares.org/files/others/wma2wav-2011-10-01.zip
Briefly tested on win 10 and win 11 x64. I'll place a proper entry on Rarewares later with the slightly amended source code.

Edit: Rarewares updated,

:goodpost: and :thanks: again ^_^