Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WMA Lossless truncates last few samples of some files. (Read 25018 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WMA Lossless truncates last few samples of some files.

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.

WMA Lossless truncates last few samples of some files.

Reply #1 –
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.

WMA Lossless truncates last few samples of some files.

Reply #2 –
It is not a header issue, I have validated this issue.

WMA Lossless truncates last few samples of some files.

Reply #4 –
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

WMA Lossless truncates last few samples of some files.

Reply #6 –
Quote from: Flepp on
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


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

WMA Lossless truncates last few samples of some files.

Reply #7 –
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]

WMA Lossless truncates last few samples of some files.

Reply #8 –
Quote from: Costas on
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.


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

WMA Lossless truncates last few samples of some files.

Reply #9 –
>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.

WMA Lossless truncates last few samples of some files.

Reply #10 –
So WMA Lossless is lossy?

WMA Lossless truncates last few samples of some files.

Reply #11 –
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.

WMA Lossless truncates last few samples of some files.

Reply #12 –
101 Error

WMA Lossless truncates last few samples of some files.

Reply #13 –
So I think somebody competent should post this issue to Microsoft then.

WMA Lossless truncates last few samples of some files.

Reply #14 –
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.

WMA Lossless truncates last few samples of some files.

Reply #15 –
Can someone confirm that *FLAC* also fails to encode it properly?  Thanks.

Quote from: maiki on
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.

WMA Lossless truncates last few samples of some files.

Reply #17 –
initially read the thread as concluding that the problem was WMAL-specific, but I wasn't sure on a re-reading.  --so the source file did not cause any problems with FLAC?  And does anyone know if this problem still arises with the most recent WMAL encoder/decoders or with the wma SDK?  Thanks.

Moderation: Removed useless quotation of previous post.

WMA Lossless truncates last few samples of some files.

Reply #18 –
Quote from: TechVsLife on
so the source file did not cause any problems with FLAC?
The file simply had some metadata that flac discarded (yes, I looked at it before the link was removed because it violated the TOS).  If the "--keep-foreign-metadata" switch had been used then it would have been kept.  This really should be self-evident from reading maiki's post.

Quote from: TechVsLife on
And does anyone know if this problem still arises with the most recent WMAL encoder/decoders or with the wma SDK?
I don't know and I'm not sure that it was ever a problem with the codec as it was implemented in WMP.

Please don't resurrect three threads asking the same basic question.  It is also a violation of the TOS, number 6 to be specific.

WMA Lossless truncates last few samples of some files.

Reply #19 –
Thanks, that hadn't been clear to me from the thread (that he failed to use the right switch in testing flac).  My apologies on the Tos Six violation.

WMA Lossless truncates last few samples of some files.

Reply #20 –
The problem was / is (still on going): the files encode correctly but will not decode using the latest WMA SDK, WMP does not use their own SDK so is unaffected.

WMA Lossless truncates last few samples of some files.

Reply #21 –
Thanks, good to know my files are ok.  I'll have to see if the decoding issue still exists when a new SDK is released for wmp12/windows7.

Moderation: Removed unnecessary quote of previous post.  Also, it is customary to put the quote above your reply.  Please try to do this in the future.

WMA Lossless truncates last few samples of some files.

Reply #23 –
I think you have seen the last WMP 11 SDK, the reason being is it has been depreciated, I think MS now expect WMA handling to use the sound API in Vista and newer to read / write WMA...interesting as even XP has been dropped, not that I think there will be much changes now to WMA.

WMA Lossless truncates last few samples of some files.

Reply #24 –
Quote
Isn't the SDK separate entity from WMP and Windows, or am I missing something?
[/size]
Separate, but I believe usually released about the same time.
Quote
Removed unnecessary quote of previous post. Also, it is customary to put the quote above your reply. Please try to do this in the future.

[/color]I'll cut back on quoting. As far as "top" posting, I actually thought that was more widely used--it's the default in gmail and outlook:
http://en.wikipedia.org/wiki/Posting_style
On the whole I find it easier to read when there IS top posting--if the message is part of a thread and one isn't cutting up the original post with interspersed replies (as here). However, when in Rome etc. Let me know if I'm in Rome.