PDA

View Full Version : .WMA files not playing correctly



fingers
2006-07-23, 08:34
I decided to try ripping a number of CD to .wma instead of .mp3. I used Windows Media Player to rip the CDs. The thing that is strange is that if I play the .wma files in Windows Media Player they all play just fine. However, when playing them with SlimServer they don't. All the tracks for each album are listed, when I start to play the album it typically plays part of the first track and then skips to another track and play part of it and then skips to another or stops playing the album all together as it has now reached the end. This is happening with every album that contains .wma files but does not happen to any of the albums that contain .mp3 files.

Any clues?

Brian Ritchie
2006-07-23, 18:23
I decided to try ripping a number of CD to .wma instead of .mp3. I used Windows Media Player to rip the CDs. The thing that is strange is that if I play the .wma files in Windows Media Player they all play just fine. However, when playing them with SlimServer they don't. All the tracks for each album are listed, when I start to play the album it typically plays part of the first track and then skips to another track and play part of it and then skips to another or stops playing the album all together as it has now reached the end. This is happening with every album that contains .wma files but does not happen to any of the albums that contain .mp3 files.

Any clues?
How are you rescanning after adding .wma tracks? Are you *replacing* any .mp3s with .wmas? Or have you been experimenting with .wma at different bitrates?

I found that when I changed even just the bitrate (never mind the format) of tracks, then it was best to do a "forget everything" scan from scratch. I got behaviour rather like what you describe when I re-ripped some tracks to .wma at a higher bitrate, and either didn't bother rescanning, or didn't do a "forget and rescan".

Apart from that (well, and that ReplayGain doesn't work for .wma), I've had no trouble with .wma files. (But I'm still switching over to .flac, having got fed up with lossy transcoding issues.) I've not tried ripping with Windows Media Player.

-- Brian

Ben Sandee
2006-07-23, 19:40
On 7/23/06, fingers <fingers.2ben0b1153668901 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I decided to try ripping a number of CD to .wma instead of .mp3. I used
> Windows Media Player to rip the CDs. The thing that is strange is that
> if I play the .wma files in Windows Media Player they all play just
> fine. However, when playing them with SlimServer they don't.


Make sure you have disabled DRM protection when ripping the WMA files. I
don't know exactly how you do this -- somewhere in the Tools->Options menu
or something. This setting would only affect future ripped files. You
might use some sort of DRM removal tool on the tracks you've already ripped?

Ben

fingers
2006-07-23, 19:57
How are you rescanning after adding .wma tracks? Are you *replacing* any .mp3s with .wmas? Or have you been experimenting with .wma at different bitrates?

I found that when I changed even just the bitrate (never mind the format) of tracks, then it was best to do a "forget everything" scan from scratch. I got behaviour rather like what you describe when I re-ripped some tracks to .wma at a higher bitrate, and either didn't bother rescanning, or didn't do a "forget and rescan".

Apart from that (well, and that ReplayGain doesn't work for .wma), I've had no trouble with .wma files. (But I'm still switching over to .flac, having got fed up with lossy transcoding issues.) I've not tried ripping with Windows Media Player.

-- Brian
? rescanning?

fingers
2006-07-23, 19:58
On 7/23/06, fingers <fingers.2ben0b1153668901 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I decided to try ripping a number of CD to .wma instead of .mp3. I used
> Windows Media Player to rip the CDs. The thing that is strange is that
> if I play the .wma files in Windows Media Player they all play just
> fine. However, when playing them with SlimServer they don't.


Make sure you have disabled DRM protection when ripping the WMA files. I
don't know exactly how you do this -- somewhere in the Tools->Options menu
or something. This setting would only affect future ripped files. You
might use some sort of DRM removal tool on the tracks you've already ripped?

Ben
? DRM? What's that?

snarlydwarf
2006-07-23, 20:55
Digital Rights Management.

For reasons known only to Microsoft: when you rip a CD using WMA, it likes to encrypt them so they will only work on your machine.

Why? No clue...

Look under Tools, Options, and the Rip tab. There is a setting called "Copy protect music" there when you have WMA selected.

fingers
2006-07-24, 07:39
? rescanning?

Oh sorry.. I got it. Yes, I have done a scan from scatch a couple times to see if that would do the trick. But it doesn't

fingers
2006-07-24, 07:42
Digital Rights Management.

For reasons known only to Microsoft: when you rip a CD using WMA, it likes to encrypt them so they will only work on your machine.

Why? No clue...

Look under Tools, Options, and the Rip tab. There is a setting called "Copy protect music" there when you have WMA selected.

I checked and Copy Protect Music is not selected.

fingers
2006-08-09, 13:03
Here's some other interesting information. When I first copy the .wma files to the Music Folder, browse through SlimServer to the Music Folder, find the particular album and play, all plays well. However, when I then tell SlimServer to find new music, including trying to clear all and find new, it appears that process corrupts the .wma files. Not all, but a few in each folder. I can copy the .wma files back from my backup share, play them again through SlimServer prior to telling SlimServer to find new music. Same thing happens once I do, some of the .wma files in each folder containing them become corrupted. However, not the same ones each time.

Brian Ritchie
2006-08-10, 16:35
Here's some other interesting information. When I first copy the .wma files to the Music Folder, browse through SlimServer to the Music Folder, find the particular album and play, all plays well. However, when I then tell SlimServer to find new music, including trying to clear all and find new, it appears that process corrupts the .wma files. Not all, but a few in each folder. I can copy the .wma files back from my backup share, play them again through SlimServer prior to telling SlimServer to find new music. Same thing happens once I do, some of the .wma files in each folder containing them become corrupted. However, not the same ones each time.

Sounds odd. I've never noticed anything like this happening.

I'd be surprised if scanning modifies the files. When you say "[the] process corrupts [some of] the .wma files", do you mean that the actual files are corrupted? Do the file sizes or modification times change in comparison with your backup? If not, then that would suggest that SlimServer's DB is getting confused somehow.

I wonder: might be worth checking that you're using a reasonably recent version of WMP.

-- Brian

fingers
2006-08-10, 16:54
Sounds odd. I've never noticed anything like this happening.

I'd be surprised if scanning modifies the files. When you say "[the] process corrupts [some of] the .wma files", do you mean that the actual files are corrupted? Do the file sizes or modification times change in comparison with your backup? If not, then that would suggest that SlimServer's DB is getting confused somehow.

I wonder: might be worth checking that you're using a reasonably recent version of WMP.

-- Brian
Yes, the actual files become corrupted. Slim Server starts skipping through the corrupted files. Even WMP refuses to play them after this happens giving an error message that the files are corrupted. Yes, the file sizes change. WMP is the latest version

Brian Ritchie
2006-08-11, 17:00
Yes, the actual files become corrupted. Slim Server starts skipping through the corrupted files. Even WMP refuses to play them after this happens giving an error message that the files are corrupted. Yes, the file sizes change. WMP is the latest version

Very odd! As I said, I wouldn't expect the SS scan to modify the files (but I don't know the code, and am only guessing; who knows how scanning WMA files works?)

I wonder what would happen if you set the files to be read-only... would they still get corrupted? (In which case I'd mistrust either the readonly setting (in Windows, trust b*gger all!) or your hard drive!) Would the scan itself fail (because it "needs" to change a file, but can't)?

I suppose there's also the possibility that some other process is corrupting the files; say, if you're running another music app that's changing files on the fly (possibly via a well-hidden configuration setting). (I remember once doing lots of damage to my WMA tags by foolishly letting WMP try to "fix" them for me, but I'm fairly sure I explicitly asked WMP to do it. And the files weren't rendered unplayable, just my carefully-assigned genres were replaced by those chosen by a bunch of brainless jerks with no taste :-(.)

-- Brian

fingers
2006-08-11, 20:08
No other music program running

fingers
2006-08-13, 11:10
Anyone have any ideas here? This is really annoying.

WSLam
2006-08-13, 21:34
I think you are onto something. Well, at least I think you AND I are onto something:
http://forums.slimdevices.com/showthread.php?t=26346

This only happens with the latest official slimserver.

converting to FLAC solves the issue.

fingers
2006-08-14, 07:29
Yes, I am able to fix the issue if I convert the .wma files as well. I have converted a number the albums that were .wma to .mp3 and the issue goes away.

WSLam
2006-08-14, 09:49
I am sure if this is indeed a bug, then a fix will be available soon!

Dan Sully
2006-08-14, 10:56
Please file a bug at http://bugs.slimdevices.com/

This could be an issue with reading the metadata and obtaining the correct audio offsets. It could be an issue with our WMA decoder. It could be something else.

Also - SlimServer _never_ writes out to your music files in any way.

WSLam
2006-08-17, 02:20
I believe a bug report has been created.
This is a truly annoying bug. I was just demonstrating the SB3 to my friend, and it skipped again! This is most annoying with classical music.

WSLam
2006-08-17, 02:37
The bug is at http://bugs.slimdevices.com/show_bug.cgi?id=3926

fingers
2006-08-20, 10:53
I looked at the bug today and it appears to be closed. Did this get fixed?

I did a couple tests this morning. I ran a rescan of the libary (Clear Libary and rescan everything). Once finished I again had a new folder under ARTWORK that says NO ALBUM. Inside were a number of .wma files that were corrupted. I copied my backup non corrupted files from another computer back to the Slim Server computer. Played the replaced files. All played just fine. Re-ran the same scan(Clear Libary and rescan everything. This time there were different files listed under NO ALUBM in the Browse ARTWORK view that were corrupted. I copied backup copies of these files back to the SlimServer computer, played the files just fine. Re-ran the same scan again and now different files are corrupted.

This is only happening with .wma files. Clearing run the SlimServer scan affects these files.

Brian Ritchie
2006-08-20, 19:07
I looked at the bug today and it appears to be closed. Did this get fixed?

It's closed because it's considered a duplicate of another bug (2985), discussion of which seems to be active at the moment. The title of 2985 ("WMA VBR transcoded to WAV truncated") made me wonder whether I'm not seeing the problem because I'm not using VBR; but I am (for some tracks at least). However, as far as I can tell, my SB3 is playing the WMA natively, and WMA is not being transcoded to WAV (or anything else). I suppose it's another thing you could check. (web i/f: Server Settings / File Types, and check that "Windows Media - Windows Media - (built-in)" is checked. For what it's worth, mine has 4 entries for Windows Media (the others are to FLAC, MP3 and WAV) and all are checked. I think that's the default.)


I did a couple tests this morning. I ran a rescan of the libary (Clear Libary and rescan everything). Once finished I again had a new folder under ARTWORK that says NO ALBUM. Inside were a number of .wma files that were corrupted. I copied my backup non corrupted files from another computer back to the Slim Server computer. Played the replaced files. All played just fine.
How did you play them? In WMP? Or did you try to play them in SS before re-scanning? I wonder what happens if you try? (SS can get confused if a file changes underfoot; at least, I've seen this introduce problems, but never fix them!)


Re-ran the same scan(Clear Libary and rescan everything. This time there were different files listed under NO ALUBM in the Browse ARTWORK view that were corrupted. I copied backup copies of these files back to the SlimServer computer, played the files just fine. Re-ran the same scan again and now different files are corrupted.

But *different* files, you say. Have you ever had the situation where the SAME file is corrupted again immediately afterwards? (That is, you copied it from backup, and it played OK before the scan, but not afterwards?) (See "Hmm. (no. 2)" below.)


This is only happening with .wma files. Clearing run the SlimServer scan affects these files.

Dan has said that SlimServer should not be changing your source WMA files. This suggests that any corruption you are seeing is some kind of conflict between what is there and what SlimServer *thinks* is there. So looking at them through SlimServer is probably not a good way to check whether the files themselves have become corrupted. (However, you say that a corrupted file won't play in WMP either, which implies that the file really is corrupted, and not just SlimServer's view of it.)

You mention an "ARTWORK" folder (for the first time). Is there really an ARTWORK folder on your hard drive, or do you mean the "Browse Artwork" page in SlimServer's web interface? If you mean the latter, then what happens when you go to the tracks via Browse Artist or Browse Album, and play them? (And what happens if you do this after a scan but before (or without) using Browse Artwork? It seems unlikely that the act of browsing by artwork could be the cause, but...) If they're not appearing properly under Browse Artist etc., how about looking for them with Browse Music Folder?

(Hmm: once you find a corrupted file, try this: restore the file from your backup copy. Then - without doing a rescan - find it in SlimServer by using Browse Music Folder. Better? However, I've seen SS get very confused if I try to use Browse Music Folder to "update" existing tracks, rather than to add completely new ones; so I can't really recommend this.)

The appearance of a "new" NO ALBUM "folder" (again, I suspect you mean in SlimServer's web interface, not on your hard drive) implies that SS is having trouble with the tags (or that the files really don't have any Album tag). Does this characterise all the corrupted files? (Do they always appear under Artwork / No Album, and are all (wma) files under there corrupted?)

(I've just looked at Browse Artwork on my own system. I do indeed have a No Album folder there. It contains a number of .wav files (which don't have tags, so their appearance makes sense) - and one WMA file. Aha! I thought. But it plays OK. It's a brief piece of sample music (at 64kbps CBR) that probably came with some sound app I installed ages ago, and for some reason SS has picked it up from the "All Users\Documents\My Music\Sample Music" folder. Though it has no album, the other tags look OK (as seen by SS).)

Sorry to be pedantic, but can you confirm that when you look at the tracks in Explorer (specifically, NOT via SlimServer's web interface), they have changed (size and/or modification time) on either side of the rescan? And are you certain that the actual files haven't changed before the rescan, by comparing them against the backup? But you've said that once copied from backup, they play OK, which implies that they haven't changed. Still, it's puzzling that it happens to different files each time.

Hmm (no. 2): when you find a corrupted file, and restore it from backup then rescan, are you just restoring the corrupted files, or all your files? In other words, are files that weren't corrupted on one scan being corrupted on the next scan, even though they weren't copied or otherwise changed in between?

On the other hand, if you are restoring ALL your files each time, and it turns out that some are subsequently corrupted at random, then I'd be suspicious about the copying process itself. (But just WMA files? Again, seems unlikely; though of course, if all you're copying around are WMA files, then it would be little surprise that only WMA files are being corrupted!)

I wonder whether the scan is actually completing, or is dying before all your files have been processed. If some files are causing the scan to crash, then this could leave the SlimServer DB in a mess. (I had this happen because SS assumed that a particular WMA tag was unique for each file, and one of my WMA providers was breaking this. But that was fixed before 6.2.2.) One easy-to-spot symptom of this is if the web interface reports far fewer artists, albums or tracks than you expect (at the top of the Browse Artist page, for example).

-- Brian

fingers
2006-08-20, 22:41
Wow! I will have to really sit down and read through this whole thing before I can reply to all.

However, yes, I copy the uncorrupted files back to the machine with SlimServer. I can play the uncorrupted files just fine in Windows Media Player and also in SlimServer when I first copy them over. However, once I run the full scan as I mentioned, random files become corrupted. SlimServer cannot play them and skips them and when I try to play them in Windows Media Player it says it cannot play them because they are corrupted.

Yes, the corruption is random... not the same files each time.

fingers
2006-08-21, 17:12
It's closed because it's considered a duplicate of another bug (2985), discussion of which seems to be active at the moment. The title of 2985 ("WMA VBR transcoded to WAV truncated") made me wonder whether I'm not seeing the problem because I'm not using VBR; but I am (for some tracks at least). However, as far as I can tell, my SB3 is playing the WMA natively, and WMA is not being transcoded to WAV (or anything else). I suppose it's another thing you could check. (web i/f: Server Settings / File Types, and check that "Windows Media - Windows Media - (built-in)" is checked. For what it's worth, mine has 4 entries for Windows Media (the others are to FLAC, MP3 and WAV) and all are checked. I think that's the default.)


How did you play them? In WMP? Or did you try to play them in SS before re-scanning? I wonder what happens if you try? (SS can get confused if a file changes underfoot; at least, I've seen this introduce problems, but never fix them!)



But *different* files, you say. Have you ever had the situation where the SAME file is corrupted again immediately afterwards? (That is, you copied it from backup, and it played OK before the scan, but not afterwards?) (See "Hmm. (no. 2)" below.)



Dan has said that SlimServer should not be changing your source WMA files. This suggests that any corruption you are seeing is some kind of conflict between what is there and what SlimServer *thinks* is there. So looking at them through SlimServer is probably not a good way to check whether the files themselves have become corrupted. (However, you say that a corrupted file won't play in WMP either, which implies that the file really is corrupted, and not just SlimServer's view of it.)

You mention an "ARTWORK" folder (for the first time). Is there really an ARTWORK folder on your hard drive, or do you mean the "Browse Artwork" page in SlimServer's web interface? If you mean the latter, then what happens when you go to the tracks via Browse Artist or Browse Album, and play them? (And what happens if you do this after a scan but before (or without) using Browse Artwork? It seems unlikely that the act of browsing by artwork could be the cause, but...) If they're not appearing properly under Browse Artist etc., how about looking for them with Browse Music Folder?

(Hmm: once you find a corrupted file, try this: restore the file from your backup copy. Then - without doing a rescan - find it in SlimServer by using Browse Music Folder. Better? However, I've seen SS get very confused if I try to use Browse Music Folder to "update" existing tracks, rather than to add completely new ones; so I can't really recommend this.)

The appearance of a "new" NO ALBUM "folder" (again, I suspect you mean in SlimServer's web interface, not on your hard drive) implies that SS is having trouble with the tags (or that the files really don't have any Album tag). Does this characterise all the corrupted files? (Do they always appear under Artwork / No Album, and are all (wma) files under there corrupted?)

(I've just looked at Browse Artwork on my own system. I do indeed have a No Album folder there. It contains a number of .wav files (which don't have tags, so their appearance makes sense) - and one WMA file. Aha! I thought. But it plays OK. It's a brief piece of sample music (at 64kbps CBR) that probably came with some sound app I installed ages ago, and for some reason SS has picked it up from the "All Users\Documents\My Music\Sample Music" folder. Though it has no album, the other tags look OK (as seen by SS).)

Sorry to be pedantic, but can you confirm that when you look at the tracks in Explorer (specifically, NOT via SlimServer's web interface), they have changed (size and/or modification time) on either side of the rescan? And are you certain that the actual files haven't changed before the rescan, by comparing them against the backup? But you've said that once copied from backup, they play OK, which implies that they haven't changed. Still, it's puzzling that it happens to different files each time.

Hmm (no. 2): when you find a corrupted file, and restore it from backup then rescan, are you just restoring the corrupted files, or all your files? In other words, are files that weren't corrupted on one scan being corrupted on the next scan, even though they weren't copied or otherwise changed in between?

On the other hand, if you are restoring ALL your files each time, and it turns out that some are subsequently corrupted at random, then I'd be suspicious about the copying process itself. (But just WMA files? Again, seems unlikely; though of course, if all you're copying around are WMA files, then it would be little surprise that only WMA files are being corrupted!)

I wonder whether the scan is actually completing, or is dying before all your files have been processed. If some files are causing the scan to crash, then this could leave the SlimServer DB in a mess. (I had this happen because SS assumed that a particular WMA tag was unique for each file, and one of my WMA providers was breaking this. But that was fixed before 6.2.2.) One easy-to-spot symptom of this is if the web interface reports far fewer artists, albums or tracks than you expect (at the top of the Browse Artist page, for example).

-- Brian

Under Server Settings / File Types, and check that "Windows Media - Windows Media - (built-in)" is checked.

No, there is no ARTWORK folder. No, not all the files appear in Artwork / No Album.

Sometimes the files change size after the rescan. Sometimes some of the tag information is missing after the rescan. By the way... is there a better wan to edit .wma tags other than Windows Media Player?

I have tried both restoring only the corrupted files and also all the files of a particular album. I have tried both copying over the exisiting files and removing the existing files prior to copying the backup files to SS.

I copy both .wma and mp3 files. This problem is only with .wma files. When replacing corrupted .wma files on the SS machine, I copy over my LAN from the computer sitting next to the SS computer to it.

At this moment I am listening through SS some files that I just copyied back to the SS machine from the backup machine because after my most recent scan some of these album files (.wma) became corrupted. I have not rescanned since copying the files to SS and they are playing just fine.

SS doesn't say anything about the files, it just skips over them if corrupted. It may play a bit of each but just skips over. Windows Media Player on the other hand does indeed state that WMP cannot play the file because it is corrupted.

bpa
2006-08-21, 17:40
Why not try Filemon to see what application is changing the files.

http://www.sysinternals.com/Utilities/Filemon.html

use with caution, it can prevent some apps from running but it may provide some help.

fingers
2006-08-21, 17:46
Why not try Filemon to see what application is changing the files.

http://www.sysinternals.com/Utilities/Filemon.html

use with caution, it can prevent some apps from running but it may provide some help.

Would I run this while I am scanning the library?

bpa
2006-08-21, 23:29
Filemon gathers a lots of data and slows things down a bit. Scanning the library will generate a lot of info but I think you start monitoring when you are sure no files are corrupted and then initiate scanning.

It would work best if you can reproduce the problem while scanning a small subset of your WMA files.

Brian Ritchie
2006-08-22, 17:46
Sometimes the files change size after the rescan. Sometimes some of the tag information is missing after the rescan.

This might sound like a silly question, but please bear with me: how do you know the files change size? Did you note the size of each file on your hard drive before the scan, or are you comparing against your backup copies after you find they've been corrupted? (If it's the latter, then it still might be the case that the files are corrupted before the scan too. But in that case I'd be surprised that mp3 files never get corrupted, unless you have many more wmas than mp3s and the corruption rate is low.)


By the way... is there a better wan to edit .wma tags other than Windows Media Player?

These days, I use MediaMonkey (www.mediamonkey.com), though it only supports a small (but reasonable) fixed set of tags. DBPowerAMP (no URL to hand, sorry) covers a wider range of wierd and wonderful WMA tags, and was the only tag editor that let me work around a problem with SS and the WM/URL tag. However, by the time my free use period of the extended tag set editor expired, the bug in SS was fixed, so I didn't need it any more :-).

For what it's worth, nowadays I use Exact Audio Copy to rip to FLAC, and then use MediaMonkey to convert this to WMA for my portable. (I also use MM to fix any tags I forgot to fix in EAC.)


I copy both .wma and mp3 files. This problem is only with .wma files. When replacing corrupted .wma files on the SS machine, I copy over my LAN from the computer sitting next to the SS computer to it.

This seems to rule out some low-level copying problem, unless - to be pedantic - mp3s are being corrupted too, but never to the point where they're broken (but this seems unlikely). Yet Dan says that the scan shouldn't be modifying your files. I'm mystified!

bpa's suggestion of using Filemon might be worth a try (I've not used it though), especially if it can tell which app has modified a file. However, if the corruption is random then you'll probably need to watch and scan a large number of files, which (as bpa says) might generate tons of data. (And turning on logging or monitoring is often a good way to make problems disappear :-))


At this moment I am listening through SS some files that I just copyied back to the SS machine from the backup machine because after my most recent scan some of these album files (.wma) became corrupted. I have not rescanned since copying the files to SS and they are playing just fine.

If corruption is happening randomly, then this doesn't say much (so sorry I asked about it!) If any of these files that you listened to pre-scan were to appear corrupted post-scan, then that would strongly suggest that the rescan is causing the corruption.

What might be interesting - but tangential - is that if you're loading these files into the playlist by anything other than Browse Music Folder, then SS isn't updating its DB; and this implies that SS's DB is consistent with the uncorrupted versions of the files (and that *suggests* that the file became corrupted after SS extracted its DB info from it). On the other hand, if you're using Browse Music Folder, then SS *is* updating its DB, and that wouldn't say much (well, except that whatever Browse Music Folder is doing isn't corrupting the files (at least, not this time!))


SS doesn't say anything about the files, it just skips over them if corrupted. It may play a bit of each but just skips over. Windows Media Player on the other hand does indeed state that WMP cannot play the file because it is corrupted.

I don't know for sure, but SS seems to believe whatever is in its DB, and will start trying to play a file until something goes wrong (which might be at the start, of course). I got truncated-play behaviour when I replaced 96kbps files with 160kbps files and didn't bother to rescan.

WMP is probably analysing the whole file (well, maybe just doing some kind of checksum test).

Does WMP complain about the file when you load it into its playlist, or only when you actually try to play it? If its the former, then a quick way to find corrupted files would be to load them all into WMP's playlist; so doing this before a SS rescan might answer once and for all my question about whether files are being randomly corrupted before the scan. But then, building such a playlist might not be so quick :-(. I sometimes use WMP to check consistency of playlists, because missing files (misspelled or moved) in playlists look really obvious in WMP - it doesn't replace the filename with the tag info.

Sigh. I'm running out of things to suggest you try, or possible causes. (Clutching at straws now: funny character sets in tags?) Maybe this should be submitted as a separate bug report so the real engineers will give it some attention. (It's not obvious to me that it's the same problem as the other reports mentioned here.)

It would be so easy just to say, stop using WMA! But if you're anything like me... I'd love to drop WMA (at least from my SS's library), but I have a huge number of WMA files (legacy from my portable-only days) that will take months to re-rip; and quite a few where that isn't an option.

-- Brian