Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jakester]

I read somewhere that the WMA encoder, even Lossless WMA, always uses the Normalize function and hence does not make perfect copies.  If I do not check the "normalize before encoding" box on Media Center (with the Lossless WMA encoding option and in digital secure mode) will I get bit-perfect copies with no normalization?

Also, any comments on pros/cons of Lossless WMA versus Monkey's Audio?  It seems there is a better chance of finding media receivers and portable systems supporting Lossless WMA in the near future.  Will I loose anything by using Lossless WMA rather than APE?

Thanks all.

[LonWar]

Both WMA Lossless and .ape will give you bit perfect copies...


As far as is one any better, I think ape updates tags faster. And there is a resident monkey on the MC team (Matt)

[Jakester]

imjustagamer -

Thanks.  I knew Matt was Father APE, which makes APE very tempting.  Have never heard of any device that supports APE, though.  Shame.  I want to be able to use Media Receivers and portable devices.  Lossless WMA is only supported on one such device at this point that I know of, but at least there's one!  And probably more to follow? ...

[xen-uno]

FYI: Lossless flac may have the largest external (outside of a computer) support...

Flac page excerpt (http://flac.sourceforge.net/faq.html#general__hardware)

What hardware products support FLAC?

    * Home audio equipment:
          - AudioReQuest music servers
          - PhatNoise Home Digital Media Player
          - Rio Reciever and Dell Digital Audio Receiver via RioPlay client
          - The Roku Soundbridge
          - The Squeezebox and SliMP3 networked audio players
          - Turtle Beach's AudioTron via Bery Rinaldo's Samba VFS Module
    * Car audio equipment:
          - The PhatBox
          - Kenwood Music Keg
    * Portable audio equipment:
          - The Rio Karma

10^-27

[Alex B]

I got interested in this WMA lossless/normalizing issue, so I did a little test.

I took a small OGG file (16 seconds) and converted it to wave. The resulting file was only 14 seconds long. Then I converted this wave file to APE (14 seconds) and WMA lossless (13 seconds). I imported new APE and WMA files and converted them back to wave. Both files are now 12 seconds according to MC.

I'm shocked. What happened here? Where are the bit-perfect lossless copies? Especially in the case of Wave to APE and back to Wave.

When I open these three wave files in Media Editor they all have visually different endings and the exact lengths are different too:

Original Wave: 14.01 seconds
Wave -> APE -> Wave: 12.35  seconds
Wave -> WMA lossless -> Wave 12.68 seconds

I did all conversions with MC 10.0.148.

P.S. I also converted the original OGG file to Wave with oggdropXPd tool and the resulting wave file is 16.7 seconds long in MC Media Editor.

P.S. 2. Can this be the cause? From the 10.0.149 thread:
"2. Fixed: MC could cut off the ends of tracks in some cases. (introduced in 10.0.146)"
Do lossless file conversions go through the MC playback engine? If so, how they can be lossless? Or shall I take that literally: Is MC 10.0.148 cutting the files on disk in some cases? How about my other 17451 media files? Are they safe?

[Matt]

Alex, please try the latest build.

The core decoding engine could cut off the end of the track.  Note that this bug only existed for a few days, and never in the main download build.

[Alex B]

Thanks for the answer, Matt.

I did the test again with 10.0.149. Results:

Ogg 16.70 s
Ogg -> wave: 16.70 s
Wave -> APE -> Wave : 16.70 s (comp.exe says: Files compare OK)
Wave -> WMA lossless -> Wave: 16.99 s (comp.exe says: Files are different sizes. That file also looks quite different in Media Editor.)

So it's working again in 10.0.149. APE is lossless and WMA lossless is not lossless.

I upgraded to 10.0.148 from 10.0.145 at June 17th, because I had the "last file ending too early" playback problem. It was working better after that. Some days ago I read about changes in 149, but I didn't realize that "cut off the ends of tracks" bug can affect actual media files on disk. I thought that it was only a playback thing.

Between June 18th and yesterday I did lots of maintenance in my Media Library. New hard drives, new locations, lots of tagging, analyzing and also some ripping and file conversions and my backups are also now up-to-date with recent files. Most of the work was done with MC 10.0.148.

Should I expect problems with modified files? MC reports that I have modified 4319 files during that time. In which cases the bug affected file lengths?

Alex

[Jakester]

Matt, Alex B -

Please keep this thread going until we find the answer here!  If WMA Lossless is not really lossless the users need to know this.

Thanks for the effort so far ...

[Omni]

If WMA Lossless is not really lossless the users need to know this.

To clarify things, WMA Lossless is lossless.  It's MC's internal handling of things that's at question here.

[GHammer]

I was never clear.

It is 'lossless' or mathmatically lossless?

[Alex B]

Lossless in case of APE or FLAC should be lossless. So files compressed from wave and then back to wave are bit to bit identical with the original if everything works.

With WMA lossless I don't know. I also converted my test wave file to WMA lossless (100%) with Microsoft Windows Media Encoder 9 and then back to Wave with MC 10.0.149 and the files were different. Is there any other software to convert WMA lossless back to Wave?

My main concern is now if there are corrupted files in my library because of the bug in 10.0.148. For example: I did conversions from my old APE 3.97 Extra High files to wave and then to APE 3.99 Normal to lessen processor usage. I believed that lossless is lossless.

[Omni]

With WMA lossless I don't know. I also converted my test wave file to WMA lossless (100%) with Microsoft Windows Media Encoder 9 and then back to Wave with MC 10.0.149 and the files were different. Is there any other software to convert WMA lossless back to Wave?

Yes.  dBpowerAMP Music Converter.

Try it.  It's free.  (There's a "Power" version--which I bought--but it's not really worth the money IMHO.)  Don't forget to download the codecs as well!

Anyway, if you use this, you will find that going from wave-->WMA9_Lossless-->wave yields a bit-for-bit identical file.

No, if[/b] there is a problem--I am not confirming that there is!--then the problem is in MC and how it handles the converted buffers.

[Omni]

Also, though it's more trouble, you can always just use WMP 9.0 to burn the WMA file to a CD-RW, and then use MC (or whatever) to rip the file back to wave.

[Alex B]

I can confirm next (at least in case of my short test file):

Wave -> WMA lossless by Windows Media Encoder -> Wave by Foobar 2000
is truly lossless. The resulting wave file is identical with the original.

Wave -> WMA lossless by MC 10.0.149-> Wave by Foobar 2000 is not lossless. Files are different.

Wave -> WMA lossless by Windows Media Encoder -> Wave by MC 10.0.149 is not lossless. Files are different.

And as I stated earlier: Wave -> WMA lossless by MC 10.0.149 -> Wave by MC 10.0.149 is not lossless. Files are different.


Matt, or somebody else who knows, can you please answer to my earlier questions concerning about possible corruption in my library?

... Should I expect problems with modified files? MC reports that I have modified 4319 files during that time. In which cases the bug affected file lengths?

... My main concern is now if there are corrupted files in my library because of the bug in 10.0.148. For example: I did conversions from my old APE 3.97 Extra High files to wave and then to APE 3.99 Normal to lessen processor usage. I believed that lossless is lossless.

I think that I have to check all possible files for corruption. It maybe difficult to find chopped files by listening because of the usual fade-outs. Some of the files are really unique. They were recorded from vinyl and corrected in Sound Laundry before converting to ape.

[Jakester]

Bump

[Matt]

We'll dig a little.  WAV files can not be bit-for-bit matches, but still have the same bit-perfect audio. (because of header differences)

Also, the end of track bug affected conversion and playback.  It was unrelated to tagging.

[Omni]

WAV files can not be bit-for-bit matches, but still have the same bit-perfect audio. (because of header differences)

Maybe I am misunderstanding your context, but yes, standard, plain-jane wave files will be identical, bit-for-bit, including the header.

These RIFF files only contain a "fmt " block and a "data" block, both of which should be identical before and after the conversion process.

But maybe you only talking about MC-generated wave files?  Where maybe you do add an info block with a timestamp or something?  If so, then, um, never  mind.  

[Matt]

WAV files can not be bit-for-bit matches, but still have the same bit-perfect audio. (because of header differences)

Maybe I am misunderstanding your context, but yes, standard, plain-jane wave files will be identical, bit-for-bit, including the header.

Simple wave files can have 44 or 46 byte headers - depending on the formatting of the 'fmt ' block.

Also, it looks like the lossless WMA decoder in MC doesn't always get the last few samples output in MC 10.0.149.  This will be fixed in the next build.

[Alex B]

In this case Wave from APE is identical with the original. I have those both open in Notepad just now.

In the case of the WMA lossless and MC10 something is really not working. It's easy to see in Media Editor that the audio content is different.

---

Here is an example of what happened to some of my files during conversions with MC10.0.148:



After conversion one of the 12 files in this album is 48 seconds shorter than original ape was. Other eleven files are OK.

It's going to be a hard work to pick chopped files up from those 4319 files I did modify with MC10.0.148. Happily most of the work included only tagging and analyzing.

I guess I have to do analyzing again, if I like it to be as accurate as possible. I have no way to find out which files were analyzed before the decoding bug. Confirm, Matt?

What about files ripped with MC10.0.148? If I understand correctly decoding engine is included in the process. Files are first saved to wave and then converted to the end format.

I think there should have been a clear warning to users of 146-148, that the bug can chop files on disk. All the discussion about the bug before the 149 release was only about playback.

[Matt]

Only converting and playback were affected by the bug.

Ripping, encoding, and tagging were not.  Analyzing would be affected so little that it's a non-issue.

Sorry for any hassles the bug caused.  This is why we don't put changes out to the masses right away -- sometimes they have unexpected side effects.

Thanks.

[Jakester]

Matt -

Sorry for such a neophyte question, but does a new "build" mean a new version (.150?), or does .149 go through builds on a regular basis?  If so, how do I know when the WMA Lossless bug fix build is complete?  Thanks.

[Matt]

Matt -

Sorry for such a neophyte question, but does a new "build" mean a new version (.150?), or does .149 go through builds on a regular basis?  If so, how do I know when the WMA Lossless bug fix build is complete?  Thanks.

Each build is a new number after the 10.0.  10.0.150 will be the next one.

If possible speed bumps are a huge deal to you, we recommend the build here:
http://www.musicex.com/mediacenter/download.html

We don't move a build to the download page until it gets used fairly heavily and known "showstopper" bugs are fixed.

[Jakester]

Matt -

Doesn't version .146 have the dreaded "chopped files" problem I've read about?  (Still unclear on this problem, but it sounds bad.)

Also, is WMA Lossless known to be truly lossless in .146?  Thanks.

[Matt]

Update on the WMA decoding issue:

Up to a millisecond can get chopped off the end because of a Microsoft bug.  The Window's Media SDK returns a rounded down length for how long the file is, but actually outputs a non-rounded length when decoding.

For CD burning to have perfect track boundaries, we need to trust the length when we ask, so that explains the difference.

Keep in mind that the difference is less than one millisecond, and doesn't affect the bit-perfect nature of the audio.  Also, this bug doesn't affect APE lossless in any way.

This probably won't be changed for version 10.  MC 11 will get the last millisecond out during conversion, but will still have to crop it during burning.

Hopefully Microsoft will address this in the future.  Thanks.

[Alex B]

Matt, thanks for your earlier answer.

About the losssless WMA, here is what I see in Media Editor. The APE sample looks perfect to my eye, but I don't believe that there is any bit-perfect nature left in the WMA "lossless" sample. You can also see the missing millisecond (lenght is only 16.99 s).

(Only one channel is shown. The other has similar differences.)

[Matt]

Media Editor shows the height of one sample instead of the peak over a range of samples, so comparing pictures from it doesn't mean too much.  If one file is a little different length, the pictures could look different.

Using a binary compare tool (like what's built into Total Commander) is safer.

From any test I've run, WMA Lossless is lossless.  

Since the next build of MC 11 will work around the duration bug to output the last MS, maybe you could test some more with it.

Thanks Alex.

[Alex B]

Here is one more picture for the road. File was made from the same original wave. WMA lossless encoder was Microsoft Windows Media Encoder v9.0 and wave decoder was Foobar 2000 v0.82.

This picture looks indentical with the original. Maybe because the file length is also the original 16.70 seconds? Obviously those programs can handle the last millisecond bug.
Also Windows XP's Comp.exe results: files compare OK.

[Alex B]

Media Editor shows the height of one sample instead of the peak over a range of samples, so comparing pictures from it doesn't mean too much.  If one file is a little different length, the pictures could look different.

I did more pictures. Maybe I'm a picture maniac. This time extreme close-ups. Now I can see what you mean. Pictures are now identical until the missing part at 16.699 seconds or something. The last missing part makes the differences seen in earlier pictures. So for all practical purposes WMA lossless is lossless also in MC.

[Omni]

From any test I've run, WMA Lossless is lossless.

I have done extensive testing (in the past) on this as well, and I completely concur.


Come on, people, stop this madness.      


Or better yet, just switch to APE!