Hi all,
A fre:ac user recently told me that his 24 bit WMA Lossless files could not be converted with my software. Also, they would not play in any Windows player he tried. It was a big deal for him as he had his whole music collection in WMA Lossless and feared losing it.
I investigated and found that Windows 10 1809 breaks 24 bit WMA Lossless decoding with the older Windows Media Format API. Many popular applications like fre:ac, foobar2000, Winamp and GoldWave use this API and are now unable to decode or play 24 bit WMA Lossless files. This potentially affects lots of users.
It's easy to reproduce: Just take any audio file and convert it to 24 bit WMA Lossless with any program that supports it (e.g. fre:ac or GoldWave; you can use 16 bit source files for this test if you don't have any 24 bit material). Then try to play the file in one of the mentioned applications.
The newer Media Foundation API does not seem to be affected as programs like Windows Media Player or Groove still play these files just fine.
The bug was introduced with the 1809 feature update and is still present in the latest insider build 18329. I have reported it in the feature hub, but it did not get a lot of attention yet. Thus I hope to find some users and developers here who care about this and would like to help by voting and commenting on the bug in Windows 10 Feedback Hub. To vote or comment on the bug, search for Feedback Hub in the start menu, open it and then search for WMA there to bring up the ticket.
Edit: Here's the link to the ticket: https://aka.ms/AA432mg
Thanks for your attention and help!
Cheers,
Robert
Maybe he could use Windows 7 and convert his files to FLAC.
Avoid using anything like Windows Media Audio / Video unless you enjoy losing access to your stuff at some point in the future. Same goes for junk like Real Player (if anybody still uses that piece of garbage),
Either use a universally supported format (all devices support it kind of thing) or at the bare minimum something that's at least open source.
I suggest your friend converts all that WMA Lossless to FLAC.
@tehabe,
@Chibisteven: Sure he can use an older version of Windows or a different software to convert to FLAC (e.g. VLC is not affected as it is using ffmpeg to decode WMA Lossless), but that's not the point of my post.
The point is that this is a bug in Windows 10 and we need to get it to Microsoft's attention for it to be fixed.
Btw., we can add VirtualDJ, SoundForge and XMPlay to the list of affected applications as per another user's post in Feedback Hub. Curiously, I see only his ticket on one computer and only mine on another. Anyway, if you can see either ticket (or any other related) in Feedback Hub, it would be great if you could vote for it for this to get fixed quickly.
I don't use Windows 10, so I can't. But it is likely due to the low usage of WMA in general. I really recommend converting to FLAC instead of fighting with WMA Lossless.
@tehabe, @Chibisteven: Sure he can use an older version of Windows or a different software to convert to FLAC (e.g. VLC is not affected as it is using ffmpeg to decode WMA Lossless), but that's not the point of my post.
The point is that this is a bug in Windows 10 and we need to get it to Microsoft's attention for it to be fixed.
Btw., we can add VirtualDJ, SoundForge and XMPlay to the list of affected applications as per another user's post in Feedback Hub. Curiously, I see only his ticket on one computer and only mine on another. Anyway, if you can see either ticket (or any other related) in Feedback Hub, it would be great if you could vote for it for this to get fixed quickly.
I run Windows 10 Pro 1809 x64 but I have most of the default bundled applications (excluding the store, weather, calculator) completely removed and I don't feel like screwing up my only computer to add that stuff back. I don't have the feedback hub on this system or any that I have access to.
Use FFMPEG or VLC to convert to WAV than to FLAC or skip the step in the middle and convert straight to FLAC. If need be you can use foobar2000 on an older version of Windows 10 or maybe Windows 7 or 8 on a different computer.
You should use something like Binary Comparator for foobar2000 to check and make sure everything that is converted is the same as the original. Given the current situation you may have to revert to an older feature update of Windows 10 such as 1803 or use a computer with Windows 7 / 8 to do this. Converting a large library can take a while but you will be glad that you did in the long run. Also note the quote below:
I really recommend converting to FLAC instead of fighting with WMA Lossless.
You could paste the link to your feedback entry here. The feedback hub separates what is shown based on language or location or something and for example I don't find anything with WMA search term.
You could paste the link to your feedback entry here. The feedback hub separates what is shown based on language or location or something and for example I don't find anything with WMA search term.
Unfortunately - as far as I know - the Feedback Hub is not available on the web yet. On https://insider.windows.com/en-us/fb/ I get
This content is available only in the Feedback Hub app on Windows 10. So no link possible it seems.
The language/area separation with no way to get around indeed makes it really difficult to work on issues together... ::)
There should be a share button in the top right corner which gives you a link. The link opens in Feedback Hub and allows circumventing the region boundaries.
There should be a share button in the top right corner which gives you a link. The link opens in Feedback Hub and allows circumventing the region boundaries.
Ah great! Didn't see that. Here it is: https://aka.ms/AA432mg
The newer Media Foundation API does not seem to be affected as programs like Windows Media Player or Groove still play these files just fine.
I created a 24-bit WMA just now to check this. My stuff uses MF to decode WMA to LPCM. The decoded output of a 24-bit WMA-LL track is garbage in 1809. In 1803 the WMA-LL output is as expected. I don't think Groove or WMP uses MF for decoding WMA. Could be secret sauce (MS doing MF calls differently), but more likely MS is not using MF for its own players.
I created a 24-bit WMA just now to check this. My stuff uses MF to decode WMA to LPCM. The decoded output of a 24-bit WMA-LL track is garbage in 1809. In 1803 the WMA-LL output is as expected.
That's strange. I built a Media Foundation based decoder for the company I work for and it handles 24 bit WMA-LL just fine while fre:ac fails to decode it using WMF on the same system.
My Media Foundation decoder uses the simple MFCreateSourceReaderFromByteStream API.
Older thread in fb2k forum: https://hydrogenaud.io/index.php/topic,117116.0.html
That's strange....
I use:
MFCreateSourceResolver
:
CreateObjectFromByteStream
:
MFCreateSourceReaderFromMediaSource
:
I use:
MFCreateSourceReaderFromMediaSource
Just tried and this works for me:
IMFSourceResolver* resolver;
IMFMediaSource* source;
MF_OBJECT_TYPE objectType;
MFCreateSourceResolver (&resolver);
resolver->CreateObjectFromByteStream (byteStream, NULL, MF_RESOLUTION_MEDIASOURCE | MF_RESOLUTION_CONTENT_DOES_NOT_HAVE_TO_MATCH_EXTENSION_OR_MIME_TYPE, NULL, &objectType, (::IUnknown**)&source);
MFCreateSourceReaderFromMediaSource (source, NULL, &reader);
It does not matter if I pass the filename as the second argument to CreateObjectFromByteStream or pass MF_RESOLUTION_CONTENT_DOES_NOT_HAVE_TO_MATCH_EXTENSION_OR_MIME_TYPE. Both create a working media source.
My IMFByteStream does not implement the IMFAttributes interface, so I cannot quickly try setting the MF_BYTESTREAM_CONTENT_TYPE attribute instead.
Well this is alarming. I have all my music stored in wma lossless and use wma pro for my portable versions. I do not use Windows 10 very often, but I plan to finish a new computer soon and it will have it. In fact, I'm building the computer for music processing and storage.
Well this is alarming. I have all my music stored in wma lossless and use wma pro for my portable versions. I do not use Windows 10 very often, but I plan to finish a new computer soon and it will have it. In fact, I'm building the computer for music processing and storage.
My understanding is that this only affects 24 bit WMA lossless, but I understand your concern about how MS supports their own formats.
An example of why proprietary formats can be dangerous in the long term.
It does not matter if I pass the filename as the second argument to CreateObjectFromByteStream or pass MF_RESOLUTION_CONTENT_DOES_NOT_HAVE_TO_MATCH_EXTENSION_OR_MIME_TYPE. Both create a working media source.
I use the filename, and "MF_RESOLUTION_MEDIASOURCE | MF_RESOLUTION_READ". I have not looked into this at all (yet). Just to see if it was a 24-in-32 container problem (another 1809 change) I played a wma-pro 24-bit back fine.
Since I know my sole 24-bit WMA-LL doesn't work (in 1809, that is), if it's simple for you, how about uploading here a 24-bit WMA-LL that works for you.
WMA is likely to be depreciated in Windows before long, but it won't really matter since it has all been reverse engineered and implemented in ffmpeg. Hell, we have WMA/WMAPRO decoders running in Rockbox (using only fixed precision no less!).
[...] and implemented in ffmpeg.[...]
wmalossless NOT implemented in ffmpeg. or not already?
It is implemented in ffmpeg, partially. Last I checked a particular test file, it didn't support short (silent?) blocks on the end, so the file was slightly truncated.
[...] and implemented in ffmpeg.[...]
wmalossless NOT implemented in ffmpeg. or not already?
It is definitely implemented in ffmpeg. It used to have problems with 24 bit files and would warn if you tried to decode them, but that was fixed. I think it mostly works now, but I bet there are still problem cases out there.
[...] if you tried to decode [...]
conversation, like, was about coding
[...] if you tried to decode [...]
conversation, like, was about coding
What is your question?
holy cow! sorry for my bad english, no question. :)
"WMA is likely to be depreciated in Windows before long, but it won't really matter since it has all been reverse engineered and implemented in ffmpeg."
I thought it was about encoding.
holy cow! sorry for my bad english, no question. :)
"WMA is likely to be depreciated in Windows before long, but it won't really matter since it has all been reverse engineered and implemented in ffmpeg."
I thought it was about encoding.
No, decoding so that people can play existing files. WMA Lossless is a nearly dead format, so hopefully no one is making new files, only converting to something modern.
Since I know my sole 24-bit WMA-LL doesn't work (in 1809, that is), if it's simple for you, how about uploading here a 24-bit WMA-LL that works for you.
Sorry for getting back at this only now! Here's a short sample (https://freac.org/development/wmal24-sample.wma) created with GoldWave that plays fine in Groove and with my own MF decoder implementation. Neither foobar2000 nor GoldWave nor fre:ac can play this though.
Neither foobar2000 nor GoldWave nor fre:ac can play this though.
This shows how it is here: https://hydrogenaud.io/index.php/topic,117300.new.html (https://hydrogenaud.io/index.php/topic,117300.new.html)
This shows how it is here: https://hydrogenaud.io/index.php/topic,117300.new.html (https://hydrogenaud.io/index.php/topic,117300.new.html)
Sounds exactly like what I get in fre:ac with the Media Format SDK based decoder. I'll try to get a Media Foundation based decoder running in fre:ac probably this weekend to compare to the (working) one I built at my workplace.
Sounds exactly like what I get in fre:ac with the Media Format SDK based decoder. I'll try to get a Media Foundation based decoder running in fre:ac probably this weekend to compare to the (working) one I built at my workplace.
I should have taken the time to just look at the wav data. This is wrong right from the very first m_IsrcReaderPtr->ReadSample(). The 1803*.wav -- correct in every way -- at
https://hydrogenaud.io/index.php/topic,117300.new.html (https://hydrogenaud.io/index.php/topic,117300.new.html)
is from the same EXE that made the two 1809*.wav files. Two 1809s because each run has different PCM data. Wrong data, of course. I tried this in Windows 10 19H1N1 and still a problem there.
Looking at the only place that matters, these
ConvertToContiguousBuffer(&ImediaBufferPtr);
:
Lock(&sampleBufferPtr, nullptr, &sampleBufferBytes);
show the data at sampleBufferPtr (for those bytes) are not decoded wma, but what look like unitialized process heap. For example, the first 128 bits are obviously two 64-bit pointers with addresses close to the process followed by 00s (but I've seen other garbage at other times). The same code decodes 16-bit wma lossless without a problem (and also fine for mp3, aac, all other wma, and adpcm; for flac, vorbis, opus, and alac I use xiph and apple source). Just for the record, this same code works fine for this same 24-bit wma lossless file in 1803 and before. And no, no reported errors along the way. For now, I'll wait and see if this becomes a known problem, with a fix.
WMA Lossless is a nearly dead format, so hopefully no one is making new files, only converting to something modern.
Part of my processing bumps up the sample rate to 48kHz for more accuracy (in declipping). WMA doesn't have the option to store 48kHz in 16 bit.
I suppose I could join the free lossless audio codec bandwagon. I'm just not sure if I've forgiven some people for the attitude they had towards those who didn't use it soon after it came out. More so, I don't want my attitude to change into theirs, if I change.
WMA Lossless is a nearly dead format, so hopefully no one is making new files, only converting to something modern.
comrade, please, be more accurate with links... thank you.
I'm just not sure if I've forgiven some people for the attitude they had towards those who didn't use it soon after it came out. More so, I don't want my attitude to change into theirs, if I change.
FWIW, this is a dumb reason to pick a format, but if you really don't like FLAC, just use one of the half dozen alternatives that are well supported and have actual documentation. The problem with WMAL is not that it isn't "free", but rather that it isn't documented and that the vendor who produced it lost interest in it almost immediately after launching it.
My Media Foundation based decoder that successfully decodes 24 bit WMA Lossless is now available in fre:ac's/BoCA's git repo (https://github.com/enzo1982/BoCA/tree/master/components/decoder/mediafoundation). The next fre:ac 1.1 alpha release will include this.
@40th.com: Maybe you could have a look at this and compare it to your code. It would be interesting what's the difference that makes my code work and yours fail.
No real difference in the code. My SWAG is, no manifest in yours. See if adding this compatibility section breaks freac. (Update: probably not; didn't fix anything when I did it to jb2112, but who knows).
:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Win10 supportedOS Id -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></supportedOS>
</application>
</compatibility>
:
I'd do it myself but, while I get everything to build for freac, or so it seems (tagidv2 or something failed to compile -- my guess that is not important; I'm using vs2019rc2), there are no decoders available. wma comes up as, Error: unknown file type. I have no idea what to do. The exes, smooth, and boca dlls, including wma enc/dec/tag, are in the same directory.
BTW, my fix is to mark wma-ll 24-bit as unsupported in Windows 1809+. The Easy Fix(tm).
P.S. Saw you guessing at wma-ll file type -
from: components\decoder\wma\wma.cpp
/*Try to guess if this is a lossless file.*/
did I see that right? This can do it:
GUID stGuid = {0};
hr = m_ImediaSourceTypePtr->GetGUID(MF_MT_SUBTYPE, &stGuid);
:
else if ((wavFormatTag == WAVE_FORMAT_WMAUDIO2) || // 9-Oct-2016 0415: 0x161 to 0x164
(wavFormatTag == WAVE_FORMAT_WMAUDIO3) ||
(wavFormatTag == WAVE_FORMAT_WMASPDIF) || // <-- not sure if this comes in a file
(wavFormatTag == WAVE_FORMAT_WMAUDIO_LOSSLESS)) {
rc = 0;
// the m_isWma* values are set at rdr_assignMetadata.cpp
//m_isWma; // 20-Jan-2016 0420: non-zero then is wma (if set one of the below is TRUE)
//m_isWmaStd; // WMMEDIASUBTYPE_WMAudioV8 00000161-0000-0010-8000-00AA00389B71 (also v2 and v7)
//m_isWmaPro; // WMMEDIASUBTYPE_WMAudioV9 00000162-0000-0010-8000-00AA00389B71
//m_isWmaLL; // WMMEDIASUBTYPE_WMAudio_Lossless 00000163-0000-0010-8000-00AA00389B71
}
Many popular applications like fre:ac, foobar2000, Winamp and GoldWave use this API and are now unable to decode or play 24 bit WMA Lossless files. This potentially affects lots of users.
I wonder if it would be a good thing if players would give a popup warning that you are using an obsolete codec that Microsoft is breaking, and offer to "Convert while it is still possible [y/n]"
I see a downside, besides the work to do it:
It does not take more than a handful of offended zealots to spam your inbox with hatemail.
...
or use ffplay or another "true" decoder.
See if adding this compatibility section breaks freac.
No, that didn't make a difference. Also tested 32 vs. 64 bit and GCC vs. MSVC build - no difference either.
I'd do it myself but, while I get everything to build for freac, or so it seems (tagidv2 or something failed to compile -- my guess that is not important; I'm using vs2019rc2), there are no decoders available. wma comes up as, Error: unknown file type. I have no idea what to do. The exes, smooth, and boca dlls, including wma enc/dec/tag, are in the same directory.
All the BoCA DLLs should go to a
boca subfolder. At least the WMA encoder and Media Foundation decoder should be usable then. Most other codec's need their own DLLs which need to be built separately.
P.S. Saw you guessing at wma-ll file type -
Ah, yes, thanks for pointing me at this. Checking the sub-type is way better, of course. Will change it. I copied this over from the old WMFormat based decoder - it should probably be changed there as well.
My IMFByteStream does not implement the IMFAttributes interface, so I cannot quickly try setting the MF_BYTESTREAM_CONTENT_TYPE attribute instead.
Okay, one difference is that I call MFCreateFile and use
its IMFByteStream.
Okay, one difference is that I call MFCreateFile and...
That's not it.
Attached is a list of modules loaded at various stages running freac, and another list for jb2112 (on 1809, and a short list for 1803). Nothing stands out but since I assembled the list I may as well heap it in (attached .txt file). I have no idea what it could be. The calls to decode using MF are very simple. It should work. It does work in 1803. Not in 1809.
I'll try to get a Media Foundation based decoder running in fre:ac probably this weekend to compare to the (working) one I built at my workplace.
Attached is a zip that includes a very simple MF program that shows the problem. It includes the few-dozen line source file, the sample lossless 24-bit .wma, a pre-built exe (for those that want to try it without compiling), and a couple of images showing the good and the not good. Attached separately, too. If you can make
THAT work in Windows 1809 you found the problem(s).
Got it!
Inserting these lines when configuring the output media type fixes the decoding:
hr = ImediaType_DecodeTo_comPtr->SetUINT32(MF_MT_AUDIO_BITS_PER_SAMPLE, bits32);
if (FAILED(hr)) break;
hr = ImediaType_DecodeTo_comPtr->SetUINT32(MF_MT_AUDIO_PREFER_WAVEFORMATEX, TRUE);
if (FAILED(hr)) break;
So it looks like I was just lucky using MFInitMediaTypeFromWaveFormatEx. If I had done it another way, I would have run into the same issue and probably never found a way to successfully decode the files.
Documentation for MF_MT_AUDIO_PREFER_WAVEFORMATEX says
"If the attribute is TRUE, the function converts the audio media type to a WAVEFORMATEX structure whenever possible, instead of converting it to a WAVEFORMATEXTENSIBLE structure.".
Looks like not setting this flag for the output media type might trigger a bug with some format descriptor conversion inside the Media Foundation or WMA decoder engine...
Thanks.
Just did some more investigation and found that MF_MT_AUDIO_PREFER_WAVEFORMATEX does not need to be set. It's sufficient to set MF_MT_AUDIO_BLOCK_ALIGNMENT instead.
This page (https://docs.microsoft.com/en-us/windows/desktop/medfound/uncompressed-audio-media-types) advises to set some more parameters when configuring the uncompressed audio type. It's probably a good idea to fill them all.
It's sufficient to set MF_MT_AUDIO_BLOCK_ALIGNMENT instead.
That doesn't work here. I get the same bad decode as before. 6 bytes for alignment? I also did the sets suggested on the "Uncompressed Audio Media Types" page. Same bad decode.
The only thing that works is MF_MT_AUDIO_PREFER_WAVEFORMATEX. And setting the MF_MT_AUDIO_BITS_PER_SAMPLE to 24, otherwise it comes back as (valid) 16-bit samples.
Obvious question is, how does MF_MT_AUDIO_BLOCK_ALIGNMENT work there but not here?
Indeed, MF_MT_AUDIO_BLOCK_ALIGNMENT with he correct 6 bytes alignment seems to work only when MF_MT_AUDIO_PREFER_WAVEFORMATEX is also set.
It works without that here when set to the actually wrong values of 1 or 2...
Has this issue been resolved? I was testing some 24 bit WMA lossless files yesterday and Foobar was the only program I have that had a problem with them. (Of the programs listed in the opening post, I tried GoldWave and it was fine.)
Has this issue been resolved?
Yes, it was fixed with the Windows 10 1903 update. Files that didn't play in fb2k on Windows 10 1809 now play fine here.
Some programs listed above might work now even without that update, if they have been updated to use one of the work-arounds mentioned here.
And there was this
https://hydrogenaud.io/index.php/topic,117578.0.html (https://hydrogenaud.io/index.php/topic,117578.0.html)
about something similar: foobar2000 v1.4.4 vs WMA Lossless
The issue from the thread 40th.com linked is still present in 1903 with the latest cumulative update. The built-in WMA decoder still isn't lossless for all tracks.
Doesn't surprise me that Microsoft even managed to break their own codec. They introduced FLAC support and then immediately broke it too from what I hear.
Glad I got away from the Windows clown car years ago. From what I hear, it's gotten a lot worse than just shifting around what gets broken. They actually foist the updates on you and then restart your computer without asking, apparently. :/
Glad I got away from the Windows clown car years ago. From what I hear, it's gotten a lot worse than just shifting around what gets broken. They actually foist the updates on you and then restart your computer without asking, apparently. :/
The update thing has actually gotten a bit better, it used to be a lot worse.