WMA Lossless is obviously supposed to fully preserve the source data, however
it appears that sometimes the last few samples of a file will be thrown away.

(Note: For those interested in recreating the problem I have uploaded a "problematic" wav file here: http://rapidshare.com/files/REMOVED* )

If I convert the above file to WMAL using dBpoweramp and Windows Media Audio 9.2 Lossless codec I get (when After Encoding Verify Audio option is checked):

Error converting to Windows Media Audio 10, '06 - Melibea - Boheme.wav' to '06 - Melibea - Boheme.wma'
Error audio file failed verification '06 - Melibea - Boheme.wma'.

If I convert the above file to WMAL using Windows Media Encoder, I get no messages but then if I bit-compare the results using foobar2000 I get:

Comparing:
"06 - Melibea - Boheme.wav"
"06 - Melibea - Boheme.wma"
Comparing failed (length mismatch : 5:35.440000 vs 5:35.439819, 14792904 vs 14792896 samples).

Can anyone help?

Moderation: Removed sample. I haven't downloaded it but from the size of it it is longer than the 30 sec we allow here.

I would guess that the length of the file doesn't match the length specified in the header, so when the file is converted, only the actual data are converted, leaving a file whose length doesn't match the original header. What was used to create the original wav file?

Try decoding the lossless file to wav and compare that to the original file, but compare the data only, not the headers.

It is not a header issue, I have validated this issue.

I think truncation with WMA "Lossless" has been reported before, at least at Hydrogenaudio.

Hi

I did the test with WMAL and could not find any issue.

I compared the CRC's with Dbpoweramp and found no difference.
When converting back to wav i found a small difference at the end of the file when doing a binary compare with fc/b command.
But difference was in the Meta part of the file. I removed all Metadata from both files and fc/b gave me no difference.

So your problem might have something to do with the foobar compare module.


Flepp

I can't find any more posts at the moment, but problems with truncation have been reported with other programs.

http://www.hydrogenaudio.org/forums/index....showtopic=54490

The loss of samples seems quite rare, I tried 2000 files and none did it, but I have a specific file which does.

I experienced this issue quite some time ago when I first decided to archive my CD collection losslessly. I initially chose WMA Lossless (I wasn't privy to other lossless formats yet) and encoded a number of albums. A year or so later (after much education on the subject of codecs) I decided to move to WavPack and noticed that a number of my gapless albums didn't transition as they were supposed to. There was an audible pop between tracks. I re-ripped the CD in question to see if it had always been there, and found that the transition was seamless.

(It was at this point that I became incredibly paranoid about lossless archiving, I might add.)

Since then, I've been incredibly careful and selective about how I back up my music collection. I use FLAC now and haven't looked back since. Having to go through and re-rip/encode all of those CDs was NOT something I ever want to have to do again... especially since my CD collection has only grown exponentially since then.

[EDIT: Grammar]

OK, I have downloaded and tested your WAVE file and the conclusion is:

your wave file is corrupted

It contains some "metadata" that should NOT be in there.

There is absolutely nothing wrong with WMA lossless, there is absolutely nothing worng with FLAC. Both encoders encode your corrupt wave file but when I decode them back, I get a different wave than your original.

This is what FLAC encoder reports:

06.wav: 100% complete, ratio=0,67806.wav: WARNING: skipping unknown sub-chunk 'LIST' (use --keep-foreign-metadata to keep)
06.wav: wrote 40001107 bytes, ratio=0,676


comparison:

the original wave file you provided: 59 171 758 bytes
encoded into WMA lossless: 39 380 187 bytes
decoded back from WMA: 59 171 628 bytes

the original wave file you provided: 59 171 758 bytes
encoded into FLAC: 40 001 107 bytes
decoded back from FLAC: 59 171 660 bytes

Since I have tested faithfullness of lossless encoders before and it did not give me any problems with any of my CD rips regarding these issues, I highly suspect you are using a buggy software (or/and) settings to rip CDs.

note: I have just tested one of my CD rips and it gives me identical files after re-decoding using WMA lossless...


conclusion #2: WMA Lossless wins the round, your wave file takes the loss

>OK, I have downloaded and tested your WAVE file and the conclusion is:
>your wave file is corrupted
>It contains some "metadata" that should NOT be in there.

Wrong - LIST chunks are valid in Wave files, Microsoft created wave files here is their take:

http://msdn2.microsoft.com/en-us/library/ms713231.aspx
---------

I have tested the wave file above it does encode to a wma file which is missing samples. When comparing audio files, Never compare just file sizes, Never run a CRC or md5 on the whole file, run it on the uncompressed audio data inside. Our [audio crc] calculation codec says about this file:

CRC32 Filename

E28F11B9 Z:\06 - Melibea - Boheme.wav
24318D58 Z:\06 - Melibea - Boheme.wma


========================================
Audio Details for: Z:\06 - Melibea - Boheme.wav

Sample Count: 14,792,904

========================================
Audio Details for: Z:\06 - Melibea - Boheme.wma

Sample Count: 14,792,859

as you can see there are samples missing from the WMA lossless file, these samples were encoded to WMA lossless, they do not come out though.

>Since I have tested faithfullness of lossless encoders before and it did
>not give me any problems with any of my CD rips regarding these
>issues, I highly suspect you are using a buggy software (or/and)
>settings to rip CDs.

By only testing say 1000 files you might never find the bug, when millions of files are being used and compared then bugs can appear.

So WMA Lossless is lossy?

But even if we admit that the file is not corrupted, still, FLAC also fails to encode it properly. So why do you blame WMA lossless for that? Anyway, that file is strange and has been probably separated from some cue sheet.

101 Error

So I think somebody competent should post this issue to Microsoft then.

They were notified, on their own forums...back in the day I used to have the contact details of the head of WMA division, no longer though.