I am going to be getting a Zune later this week, so I am in the process of converting my library to WMAL. Unfortunatly I seem to have hit a snag.

The main issue at this point is that on some specific files the resulting WAVs (if I convert my FLAC to WAV and the WMA to WAV) are apparently not exactly the same. I used the WAV compare function in EAC to check this. The error I get is "Position" "0:00:00.000 Longer" Additionally DB Poweramp's check written audio feature trips up on the same files, claiming an error.

I have tried using the WMCmd.vbs with foobar, and the DBPoweramp beta. Both result in the same WMA file, which apparently does not match the FLAC. Any ideas guys?

EDIT: I'm not sure what this means, but the 'size' given by explorer is different between the two wavs, however the 'size on disk' is the same.

EDIT2:

just on a side note, i believe that the Zune does NOT support WMA Lossless

But the Zune management software does. On the other hand, it does not support flac. (which is what my library is in now) As I understand it, the software will transcode the WMA lossless to WMA lossy upon transfer.

why not just put all the files as lossy files instead?

Size on disk is rounded up to a whole number of clusters, so two files that are approximately the same size will usually occupy the same number of clusters and be the same size on disk.

That explains that...

From what I can tell, a few silent [frames?] are getting cut at some point in the process of converting from FLAC to WMA Lossless. I'm still trying to make sense of it.

Mainly because I don't want to be maintaining two parallel libraries. Seems like it would be a really big pain.

I went ahead and tested burning the problematic files with a cue sheet and found that it had no effect on the ability to burn an exact copy of the CD due to the fact the dropped samples are at the end of the track. I'm going to go ahead with the conversion so as to ease the usage with the Zune software.

out of curiosity, is it because of the amazon u$s 90 deal?

Nope. I just think the zune is one of the few HD based players on the market that I really like. I'm not going to buy into the MS bashing that everyone else seems to be doing. Sure some aspects of the software are in a pretty poor state right now, but its still early. I ended up paying ~225.00 including shipping for my zune.

In my opinion it's not the common, prejudiced "MS bashing" that causes most HA users to dislike the Zune player. I for my part, although mainly a FLAC/Vorbis user, am relatively open to Microsoft's audio portfolio, I've been using their Windows Media Audio 8/9 Standard codecs for quite some time before I switched to open source. Some personal tests with the new Windows Media Audio 10 Professional codec also invoked my interest for this new format, one that would play very well on the Zune player, despite any others found on the market (except some very rare exceptions).

But nonetheless, I'd never buy that thing. That's mainly due to Microsoft submissively following the music industry's dictate, having caused them to implement some annoying DRM mechanism that copy proctects any song you wanna transfer via WLAN between different Zune players. 3 times/days of playback, and the file's life span is over, even on non-commercial, free to distribute music. That's simply a joke.

Of course it's possible to workaround this restriction. But the casual user commonly either doesn't know of this workaround or simply isn't able to use it. Already annoying enough that you're forced to rely on dubious methods to use the player as you like to.

I did this test a few years ago, and noticed that the wav files were not the same too. The wav files encoded to wmaL never regenerated back to the same wav files. I wrote about it on a thread a few weeks back.
I did some tests on the last weeks, and I believe it is truncating, or removing the "silence" from some files. Test with some tracks from live albuns, which usually has some clapping from the beggining, or a Pink Floyd album, which hardly has silence in the beggining of the track, and see if the wav's come out the same...

To test the wav files after compressing, use the method on this thread: http://www.hydrogenaudio.org/forums/index....st&p=447547

I also suggest a program called compare_wav (try to find on google. If you can't, pm me and I'll try to send you). It gives a better picture showing where the wav files differ.

And please, post your results, even if you don't reach any conclusion.

Personally I wouldn't touch WMA Lossless, unless you were forced to (hardware), you can corrupt a WMA file, and it will play back without informing the application there is an error.

I noticed the same problem with WMA Lossless and a different file. Initially I was transcoding FLAC to WMAL but the same thing happened if I first decoded to WAV.

I tried various decoders and encoders and two versions of Windows just in case it was something peculiar but the WMAL encoder consistently drops the last 5 stereo samples on one particular file. They're nearly silent but, according to Audacity, not quite silent.

(It's possible they were completely silent. I'm not sure I trust Audacity but don't have anything better installed to check with. I noticed that Audacity seems to have some nasty rounding errors where, whether its set to float or 16-bit, simply loading a WAV and saving t out again slightly changes every single sample. Unless I was doing something stupid.)

I posted about the WMAL problem Microsoft's newsgroup (and referred back to this thread too) but there hasn't been any reply or acknowledgement so far:

http://groups.google.com/group/microsoft.p...bd35725459a4da3

In my case it was track 6 on the new Saul Williams album which I bought in FLAC format and converted to WMA Lossless. I have never noticed this problem with anything else, having converted hundreds of CDs to WMAL, so it must be triggered by something fairly unusual. Credit to dbPowerAmp DMC's verify option which always seemed pointless for lossless codecs before, but obviously is not!

I used to use FLAC for everything but I switched to WMA Lossless since it plays well in just about everything (unlike ALAC which only works in iTunes; I gather the FK2b ALAC plugin isn't very reliable) and can be dropped on iTunes to convert to AAC or ALAC for the iPod (unlike FLAC which iTunes doesn't understand). Another factor was the command-line version of Nero 6 not supporting FLAC (even with the plugin installed) but working with WMA Lossless. Seems you get WMAL support "for free" with a lot of things which made it attractive.

>Credit to dbPowerAmp DMC's verify option which always seemed pointless for lossless codecs before

From what I can tell it is a problem in the WMA Format SDK, Windows Media Player does not seem to suffer from this as they do not use their own SDK for their own media player.

EDIT: This is rubbish! I made a mistake. See below.

Little update on this:

This problem with the WMA-SDK seems to affect all 36 tracks on the new NIN album (ghosts.nin.com) if you try to convert the FLAC download into WMA-L.

I've added this information to the Microsoft newsgroup post, but I've got no idea if MS are actually paying any attention to that newsgroup. They certainly have not responded.

It's a damn shame since WMA-L is so convenient and widely supported on Windows.

(PS: Spoon, thanks for writing DBPowerAmp. I bought the Reference version and use it for all my ripping and conversion stuff now. It rocks!)

You might wanna check out this thread, although its title is misleading.

I skimmed through that, but it seemed to suggest there's a but in Adobe Audition's WMA decoder? I'm not using Audition. I've done test using only Microsoft's own encoding scripts from their WMA SDK (as well as DBPowerAmp, separately).

Of course, Adobe Audition may simply be calling the same SDK that the scripts and DBPowerAmp use. Either way, there's almost certainly a bug in the WMA SDK. Whether the bug is in Microsoft's WMA encoder or their decoder, or both, I don't know. (If it's just in the decoder then that's great as it means the files people have made will become correct when/if the decoder is fixed, without need for re-encoding.)

Sorry for my mistake. This was total rubbish! I had accidentally set the WMA encoder to use 24-bit mode, so of course the samples were different. Putting it back to 16-bit mode and trying again resulted in the correct results.

So there isn't a problem with any of those 36 tracks.

There is still a problem with a few particular tracks, though. (I just double-checked that using the correct settings and the Saul Williams track I had problems with months ago, and that still encodes incorrectly.)

I also think I've found a workaround for the problem:

I went back to the problematic Saul Williams album, decoded FLAC->WAV, then encoded WAV->FLAC with the "align on sector boundaries" option turned on in FLAC Frontend. I assume this rearranges the samples in the files so that each file is a multiple of the CD sector size, moving samples from the end of one file to the start of the next to correct things.

Encoding the resultant FLACs to WMA-L resulted in no errors.

Of course, only having one problematic file I cannot prove that this will always work, or that non-CD-sector aligned input files are what cause the WMA-L encoder problems. It seems plausible, though. Almost all of my music comes from CDs and is thus naturally sector-aligned, but the Saul Williams album was released on the Internet as FLAC files which presumably were never written to, or ripped from, a CD and thus were not all aligned. (The FLAC encoder said that it moved samples around, too.)

Just a theory.

I can confirm that none of the files from that album ("The Inevitable Rise and Liberation of NiggyTardust") have sample counts that are multiples of 588 (i.e. it wasn't ripped from a CD, or was subsequently altered). Same for NiN's "Ghosts I-IV". People who bought the album for download and intend to burn it on CD-R are in for a surprise...

I am trying to push through the issue with a guy in the WMA department, this is the exact testing I did (talking about 1 wave file which has problems):

============

The example Wave file encodes to WMA, but a few samples are missing when decoding.

wave-orig.wav: 6723780 samples
as-wma.wma (WMA Lossless, when decoded by dBpoweramp, or audioplayer in WMFSDK11): 6723776 samples

The WMA file was encoded to wma lossless using dBpoweramp Music Converter R12.4 and the latest WMA v10 Pro Codec, when decoded using dBpoweramp, or WMFSDK11\Samples\AudioPlayer\ (modified to write audio to disk) 4 samples are missing when decoded. When decoded with the WMA v9 wmal2pcm.exe (from Microsoft http://www.microsoft.com/Downloads/details...displaylang=en) all 6723780 samples are decoded correctly. It seems the WMA v11 Format SDK cannot decode this WMA Lossless file correctly.

===================

So the problem is decoding, the encoded files do not have anything missing (as wma 2 pcm cli program can decode correctly).

I changed the title.

Does anyone know if there is an update on this issue? Has anyone tested with the wmp12 decoder (if it's out), i.e. the one coming with Windows 7? Thanks.