Print

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

[RReid]

Thanks for the advice. I haven't ripped my CDs yet because I wanted to have all the fields in place in a check-box type input environment when I do. Haven't decided on a file format - probably WMA or WAV.

[Vincent Kars]

probably WMA or WAV

WMA is a proprietary format (MS). The moment you want to use e.g. a NAS as a streamer (DLNA) or move e.g. to JRiver on Linux, WMA won't play.
It is tied to the MS platform and not a very popular format. I do think it a dead and street.

WAV support is almost universal but tagging support is haphazard.
Some programs write ID3 tags in a info chunk. Other don't.
It is about tagging support, I won't recommend WAV
http://thewelltemperedcomputer.com/KB/WAV_KB.htm

My preference is FLAC

•Lossless.
• Excellent tagging support including cover art.
• Allows storing custom tags in the file.
• Checksum stored in the file. This allows you to verify if the audio is corrupted.
• Wide support on Win, OSX, Linux, Android.
•Lossless downloads are often in FLAC.

[6233638]

My preference is FLAC

•Lossless.
• Excellent tagging support including cover art.
• Allows storing custom tags in the file.
• Checksum stored in the file. This allows you to verify if the audio is corrupted.
• Wide support on Win, OSX, Linux, Android.
•Lossless downloads are often in FLAC.

Neither OS X nor iOS has native support for FLAC.
Many third-party players support the format, but I would use ALAC in preference to FLAC these days.

I think it supports everything that FLAC does, but is compatible with a wider range of devices.

[Vincent Kars]

Good point.
Older generation media streamers probably don't support it (it was proprietary at that time) but if I look at recent offerings like http://www.synology.com/nl-nl/dsm/index/software_spec#multimedia it is supported in the Linux world as well.

Are you sure about CRC support? http://forums.ilounge.com/itunes-related-mac-pc-applications/279721-alac-vs-flac-crc-md5-checksum.html

[6233638]

I thought it did, as dBpoweramp is able to verify the file after conversion, and there was some discussion of it here: http://yabb.jriver.com/interact/index.php?topic=88717.msg609090#msg609090
 
If there is not support for this, I wish it was more widely known as I would not have converted my library from FLAC to ALAC...
 
Can someone more knowledgeable on these matters confirm either way?

[Vincent Kars]

dBpoweramp is able to verify the file after conversion

It does so for all file formats.
When it writes to HD it probably computes the MD5
When reading back the file it does the same.
SO it can compare but this doesn't require the MD5 to be stored in a file.
Might be a nice custom tag

[whataboutbob1]

A friend pointed out to me that the format that is best is the one is not only an exact copy but one that can be transferred to the most number of other players in the future.  So loss-less formats may not be the wonderful thing they are touted to be? With wav files they are exact copies without a loss-less formula. I am not arguing that loss less isn't an exact copy or sounds any less wonderful once played. But it uses a formula that may or may not be usable in players of the future.  In other words if you do the original download in wav you are safe regardless of what changes occur in the future.

Does this make sense?

bob

[Awesome Donkey]

Lossless compression is 1:1 like WAV... if ripped correctly.

Just stick with FLAC.

A friend pointed out to me that the format that is best is the one is not only an exact copy but one that can be transferred to the most number of other players in the future.  So loss-less formats may not be the wonderful thing they are touted to be? With wav files they are exact copies without a loss-less formula.

Ummm? I think you and your friend are quite confused so let me try to explain in an understandable way. Lossless is exactly that, lossless. FLAC is lossless, WAV is lossless. Both are 1:1 bit-perfect of the source audio data (aka exact copy) IF they're ripped correctly. FLAC is compressed to save file space and while there is compressed WAV files, most WAV files I see are uncompressed. There's no loss of data involved and it's still identical to the source data (e.g. CD) assuming it was ripped correctly. There's really no benefit to use WAV over FLAC if you have a choice - if you need to you can losslessly convert FLAC to WAV and back again AND yes it's infinitely transferrable to devices and it's infinitely convertible as long as you're converting the data to a lossless compression format and not a lossy compression format. While FLAC isn't officially supported on OSX/iOS you can however convert the file to Apple Lossless (ALAC) and it'll remain an exact copy.

Think of it this way, I rip an album in Exact Audio Copy setup to output perfect FLAC rips of the album. I can convert it to uncompressed WAV then convert that to Apple Lossless (ALAC) then convert that to Monkey's Audio and finally convert that back to FLAC. Is the file still an exact copy? Yes! Why? Because I converted the file multiple times from FLAC to other lossless compression formats and back to FLAC again. Now, if you convert a lossless file (let's say FLAC) to MP3, which is a lossy compression, and back to FLAC again is it an exact copy? No! Lossy compression formats are exactly that, lossy. Basically it means by striping data from the source data it can achieve a very small size compared to the source data. Once converted to a lossy format you cannot regain the data lost in the conversion if you want to convert back to a lossless format. Also every time you convert a lossy file to another lossy file more data is lost and thus audio can and will degrade if you convert the same lossy file over and over again. Got a basic idea now?

Here's some reading about lossless and lossy compression;

https://en.wikipedia.org/wiki/Lossless_compression
https://en.wikipedia.org/wiki/Lossy_data_compression

[whataboutbob1]

I have heard arguments both ways. But...... I have NEVER heard the argument that WAV files aren't perfect copies of the originals. I guess I tend to go with 100% proof. I may need some extra room for storage but I can get a 4 TB external hard drive for 200.00 so storage is cheap. And solid state storage will be a cheaper reality soon.

[Vincent Kars]

But it uses a formula that may or may not be usable in players of the future.

It is thinkable but a bit farfetched IMHO.

Say you decided to move to OSX and your media player will be iTunes.
Your audio is FLAC.
None of them will play as iTunes don’t support FLAC
Likewise you decide to ditch JRiver and run WMP.
Again none will play as WMP don’t support FLAC.

Solutions are:
-   There are all kind of tricks to get it to work but most of the time it is a hassle
-   Convert to a (lossless) format supported by these players

In another scenario, you do exactly the same,, but this time your audio is in WAV.
It will play.
Don’t be surprised if you lose most of your tags as iTunes or WMP don’t read ID3 tags stored in a chunk at the end of a WAV file.
That’s the paradox of WAV. Support for the audio part is almost universal, support for the tags is haphazard.

IMHO the perfect lossless format supported an all possible platforms by all possible media players  both audio and tag wise doesn’t exist.
But one can always convert without loss from one lossless format to another lossless format.

[connersw]

IMHO the perfect lossless format supported an all possible platforms by all possible media players  both audio and tag wise doesn’t exist.
But one can always convert without loss from one lossless format to another lossless format.

This.  Exactly.  The perfect format across all platforms that is accepted by all players doesn't exist now, let alone being future proof.  The best you can do is go with what works for your system now.  Since I don't support Apple products in any way, for me, it is FLAC. 

[JimH]

I have heard arguments both ways. But...... I have NEVER heard the argument that WAV files aren't perfect copies of the originals.

They're fine for sound, but WAV tags aren't supported by all audio software, and the tag support that exists isn't yet reliably the same when you use different software.

FLAC may be the best compromise.  You can always convert when you need something else.

[Listener]

A friend pointed out to me that the format that is best is the one is not only an exact copy but one that can be transferred to the most number of other players in the future.  So loss-less formats may not be the wonderful thing they are touted to be? With wav files they are exact copies without a loss-less formula. I am not arguing that loss less isn't an exact copy or sounds any less wonderful once played. But it uses a formula that may or may not be usable in players of the future.  In other words if you do the original download in wav you are safe regardless of what changes occur in the future.

Does this make sense?

bob

No, it is an argument from ignorance.

If you rip CDs to Flac (or download files in Flac format), you can convert to another lossless compressed format or to any uncompressed format like WAV or AIFF without loss.  Your tag information with be in the files in a format that can be used by a wide variety of devices and will go with the files as you transfer them from one device to another.


If you rip CDs to WAV files, you may or may not have tags in the files.  For example, if you rip CDs to WAV with iTunes, the tag information is in the iTunes database but not in the music files. Copy those files to a different location and you have probably lost all the tag information. JRiver has been a leader in storing tag information in WAV files. However, the programs and devices you use to play WAV files may or may not be able to read and use tags in WAV files.

The disadvantages of ripping to WAV files are real.  If you don't understand them, you should not choose that format.

WAV is just another format that may or may not be recognized by software and devices in the future.  Audio data is stored in RIFF chunks in WAV files.  That format has to be understood by the software or device using the WAV files.

[6233638]

It is thinkable but a bit farfetched IMHO.

Say you decided to move to OSX and your media player will be iTunes.
Your audio is FLAC.
None of them will play as iTunes don’t support FLAC
Likewise you decide to ditch JRiver and run WMP.
Again none will play as WMP don’t support FLAC.

Solutions are:
-   There are all kind of tricks to get it to work but most of the time it is a hassle
-   Convert to a (lossless) format supported by these players

In another scenario, you do exactly the same,, but this time your audio is in WAV.
It will play.
Don’t be surprised if you lose most of your tags as iTunes or WMP don’t read ID3 tags stored in a chunk at the end of a WAV file.
That’s the paradox of WAV. Support for the audio part is almost universal, support for the tags is haphazard.

IMHO the perfect lossless format supported an all possible platforms by all possible media players  both audio and tag wise doesn’t exist.
But one can always convert without loss from one lossless format to another lossless format.

The most likely scenario for people is that they want to transfer files to a portable device, rather than switching to a player which does not support common lossless audio formats.
In that scenario you can store 2-3x as many tracks on the device when using lossless formats rather than uncompressed formats.

Of course these devices often have limited format support, but usually they support either FLAC or ALAC, and most new devices support ALAC now.
Apple hardware will probably never support FLAC, but other devices are adding ALAC support.


You're right that WAV is probably the only "universal" format that will play on just about anything - though I have seen some newer hardware which supports FLAC/ALAC and does not have support for WAV.
AIFF support is limited if you're on Windows rather than a Mac, FLAC does not have wide commercial support, and ALAC is not supported by many older devices.

ALAC seems to be the best format to use going forward, unless all your devices support FLAC and you won't be buying any Apple hardware.
That said, conversion between lossless formats is a painless process, and is usually not that time consuming, so your choice between the two doesn't really matter.


The huge waste of disk space, lack of widespread tagging support, and lack of internal checks for file validation mean that WAV is a poor choice to rip to, in my opinion.
Hopefully we'll get an answer next week about whether or not ALAC actually does have the same internal checks that FLAC does. That will certainly affect my decision for what format I'll be storing my library in. (but it would be a pain if it doesn't, since I do own some Apple hardware and was thinking about getting a new iPod)

[whataboutbob1]

No, it is an argument from ignorance.

Was that really necessary.

[Listener]

Was that really necessary.

I think it was an accurate statement about your line of reasoning.  It is your decision to take it as a statement about you as a person.

[Vincent Kars]

but it would be a pain if it doesn't, since I do own some Apple hardware and was thinking about getting a new iPod

What about a library in a format supporting a CRC and transcode to a portable?

[JimH]

Was that really necessary.

Listener is correct that your friend is giving you uninformed advice.  WAV has no advantage over lossless formats, and it does have some disadvantages.

[Vincent Kars]

IMHO Whataboutbob1 question is about future proofing ditgital data.

An obvious first is that it is hard to predict especially when it is about the future.

One might assume that a format with a broad support today might be the most likely candidate to survive. That might be WAV indeed. But one cannot be sure.
Another even more popular format like MP3 might not survive in the long run as its raison d'être (cost of storage) might become a moot point once all out portables have a 1 TB SD card.

Let’s assume one day you get some very valuable information on a 7” floppy.
After exhaustive research you find out this media has been used by 70’s IBM typewriters.
After spending a fortune on restoring one, you have access to the information.
A typical case where one would have appreciated a bit more future proofing of this data.

Let’s assume one has ripped one’s collection to TAK
Support for this format is meagre.
Hence one decides to convert to another lossless format e.g. APE.
Years later it looks like you are in the same boat, support for APE is dropping.
Hence one converts to XYZ
I’m inclined to say if it is about once own collection, future proofing is a moot point as we have ample of time to convert to any other format.
We can safely do so if:
-   We stick to a lossless format
-   We don’t lose our meta data
-   We can verify the result of a conversion (not all software is really flawless)

 

[Vincent Kars]

Bit more about future proofing: http://www.digitalpreservation.gov/formats/index.shtml

[whataboutbob1]

Thanks Vincent!

[6233638]

What about a library in a format supporting a CRC and transcode to a portable?

Well it's a lot more convenient when you can simply copy the files over without conversion.
 
Do we know for certain that FLAC supports this, and ALAC does not?
I'm wondering if this is something Matt or someone else on the JRiver team would be able to give us a definitive answer on.

[ferday]

Well it's a lot more convenient when you can simply copy the files over without conversion.
 
Do we know for certain that FLAC supports this, and ALAC does not?
I'm wondering if this is something Matt or someone else on the JRiver team would be able to give us a definitive answer on.

from my understanding ALAC doesn't support the md5 CRC like FLAC does, so to checksum one needs an external program (EAC automatically does it) or convert the ALAC to raw PCM (.wav) and read the md5 hash, compare to your FLAC/wav.  there are checksum other than md5.  then there's always the accuraterip database...

i can't comment on any of the other lossless formats...because really, who cares.  those guys can have their APE/AIFF/whatever...at least FLAC (and to a somewhat lesser extent ALAC) are being constantly developed by a dedicated and knowledgeable group (kind of like JRiver!).  i chose FLAC years ago because of 1. windows and 2. flawless tag support right out of the gates.

[6233638]

Well it was a bit of a scary proposition, but I converted my library from ALAC to FLAC, since it appears that FLAC files have internal validation that ALAC is lacking.
 
Using dBpoweramp it only took a couple of hours for the batch conversion, and it went relatively smoothly.
The latest version of dBpoweramp moved to 64-bit, which has made conversion noticeably faster, though I have experienced a few issues with their ALAC support. (which has been reported to them)
Both multichannel files (fixed) and mono files (pending) were reported as corrupt by the tool.
For those files, I just used Media Center to do the conversion instead.
I could probably have used the previous 32-bit version of dBpoweramp for the conversion, but didn't want to have multiple versions of it installed at once.
 
When Media Center performed the conversion, the mono files were changed to being stereo though (with no apparent increase in file size) and the embedded PNG artwork was converted to JPEG.
I no longer seem to have a copy of the original PNG art backed up anywhere, and I'm not sure how to extract it from the ALAC files.
Neither is a big problem, as it was less than 20 tracks, but it is annoying.
 
 
Before doing the conversion, I disabled auto-import in Media Center (I was converting in place and leaving the originals) and once it was finished I did a find & replace on the filenames to update them from .m4a to .flac
I also had to update the file type from M4A to FLAC too.
This meant that all my tags were retained, as some of them are only stored in the database rather than written to the file. (I'm not sure if I should just set everything to write to the file?)
 
 
Running the free version of PerfectTUNES seems to think that the audio data is the same for all the converted files, and I have just finished running Media Center's analysis on them without any errors, so the conversion seems to have been successful.
 
Overall, moving from ALAC to Level 8 FLAC (highest compression) saved me about 4GB from the ~200GB of files that I converted - not that I'm doing this to free up disk space.
 
I still have a backup which contains my Media Center library and all the original ALAC files, so that I can always revert to that if necessary - but hopefully I'll never have to.

[glynor]

Before doing the conversion, I disabled auto-import in Media Center (I was converting in place and leaving the originals) and once it was finished I did a find & replace on the filenames to update them from .m4a to .flac
I also had to update the file type from M4A to FLAC too.

You should Control-A and do Update Tags (from Library) and then immediately the reverse Update Library (from Tags).  That forces MC to (1) write out your tag data to make sure that #2 doesn't screw up tags you want, and (2) MC will then fix things like [File Type] and other file-based attributes (size, bitrate, etc).

For next time...  Don't do it manually like an animal.  

You also might have to re-do analysis. With lossless to lossless conversions, I'm fairly sure it doesn't matter (shouldn't the PCM be identical and so the analysis also be identical).  I've mostly used it for going from MP3 > FLAC or MP3 > less crappy MP3, and it does there.  However, even with those, in my tests the changes were typically very small, unless the original source was very badly encoded.

[6233638]

You should Control-A and do Update Tags (from Library) and then immediately the reverse Update Library (from Tags).  That forces MC to (1) write out your tag data to make sure that #2 doesn't screw up tags you want, and (2) MC will then fix things like [File Type] and other file-based attributes (size, bitrate, etc).

I  was going to run Update Tags (from Library) but was concerned that it might change tags which had been updated in the library but were not written to the files.
I don't know if I have any files where that's the case, but just wanted to be safe.

For next time...  Don't do it manually like an animal.  

The manual find & replace seemed like it would be quicker than learning a new tool - but I'll keep it in mind if I have to do something like this again.
 

You also might have to re-do analysis. With lossless to lossless conversions, I'm fairly sure it doesn't matter (shouldn't the PCM be identical and so the analysis also be identical).  I've mostly used it for going from MP3 > FLAC or MP3 > less crappy MP3, and it does there.  However, even with those, in my tests the changes were typically very small, unless the original source was very badly encoded.

I re-ran analysis on everything purely as a way to verify that the files are not corrupt, and to update everything so that it's using the latest version of the analysis tool. (I think some files had been analyzed using an older version)
OK, Media Center may not be the best way to verify the file integrity, but if it can pass analysis without generating errors, that's a start.
 
The results should be identical to what they were before, other than slight differences in the version used for analysis.
 
 
If you convert from lossless to lossy, I would definitely expect there to be differences - particularly with true peak level.

[Awesome Donkey]

When I converted from ALAC to FLAC 6 months ago, I just let MC handle the conversion and it worked perfectly (took two days for 60,000+ ALAC files). Since then I've also started re-ripping my CDs into FLAC.

[glynor]

I was going to run Update Tags (from Library) but was concerned that it might change tags which had been updated in the library but were not written to the files.
I don't know if I have any files where that's the case, but just wanted to be safe.

If you do Update Tags first, and then do Update Library, it flushes changes to disk, and then only changes sync back (it does not re-write any existing data that is already correct, and for those, file modified dates stay unchanged).

I can't see why you wouldn't want all of the correct data written to tags in all cases.  About the only rational reason I can think of is if having "unexpected" tags messes up some third-party utility or player.  But, I've never experienced this, and frankly...  If an alternate utility or player can't properly handle tags, then I don't want anything to do with it anyway.

But, in any case, I've never seen an instance where doing Update Tags, then Update Library immediately afterwards, causes any damage (assuming you have MC set to be able to write tags in the first place).  And, it does fix a bunch of things and is the typical solution when the file source changes "underneath" of MC for some reason and you need MC to fix the Library to match.

[6233638]

If you do Update Tags first, and then do Update Library, it flushes changes to disk, and then only changes sync back (it does not re-write any existing data that is already correct, and for those, file modified dates stay unchanged).

I can't see why you wouldn't want all of the correct data written to tags in all cases.  About the only rational reason I can think of is if having "unexpected" tags messes up some third-party utility or player.  But, I've never experienced this, and frankly...  If an alternate utility or player can't properly handle tags, then I don't want anything to do with it anyway.

But, in any case, I've never seen an instance where doing Update Tags, then Update Library immediately afterwards, causes any damage (assuming you have MC set to be able to write tags in the first place).  And, it does fix a bunch of things and is the typical solution when the file source changes "underneath" of MC for some reason and you need MC to fix the Library to match.

Yes, I see what you were telling me to do.

I think I accidentally hit "update library from tags" rather than "update tags from library" and it seems that at least some of my library did not have their tags up-to-date with what was in MC's database. Short of restoring a library backup, it seems this is not a step which can be undone.

The UI froze up as soon as I ran it, so I was unable to cancel the action.
This really needs to be an action which has you confirm twice before proceeding, rather than just running.
 
 
Fortunately it mostly seems to be the Description field which has changed (apparently MC wasn't writing those changes to disk, even though it is configured to) and I can find the affected albums by comparing to the file path, as I use Description in my folder structure.
 
Maybe I should just restore a backup and write the changes to the files though, in case there are any other discrepancies.


Edit: My main concern is that MC likes to replace (lossless) PNG artwork with (lossy) JPEGs. Hopefully "update tags from library" will not do this.
 
Edit 2: It did not. This only seems to happen during conversion, or when adding artwork via MC.

[glynor]

Maybe I should just restore a backup and write the changes to the files though, in case there are any other discrepancies.

This is exactly what I'd do.  Of course, I'd also recommend making a backup just before doing any big changes like this (and repeatedly throughout). 

But, alas, even I've gotten bit here and there.  You never think this click is going to be the one that spells doom, because you think you're on the right track.

Unfortunately, multi-level undos really aren't always practical.  For example, writing the tags out to files?  Can this be undone?  Well, only if you save all existing state on every tag write, which (of course) makes everything twice as slow (and makes the database size grow, making all other operations slower over time).  That may be a trade you'd be willing to make once in a while, but 99.99% of the time (or higher), it is useless data... So, that's a difficult compromise to make.

Even just writing changes to the Library.  Performance counts a lot when you might be tracking hundreds of thousands of assets (where each one might have hundreds of data points), and you have to be able to do it and maintain performance with whatever crazy calculated views us nutjobs dream up.

I think, if they were going to implement a change here, a better solution than bugging the user or slowing everything down, is just more liberal use of automatic backups.  If a change of any kind is of sufficient "size" to warrant a "are you sure" dialog (percent of Library, or just an arbitrary count of assets, or whatever)?  Make a backup.  Just do it.  Sure, it slows down the operation, but not by that much percentage wise if it is a big operation, and that's a small price to pay for safety.  And more practical than highly complicating the Library mechanism to allow inline undos all the time (which are complicated to manage architecturally).

[6233638]

I did end up restoring the backup, but I think it's important that you are prompted at least once before this runs on your library. (I'd be happier with twice, since this is potentially very destructive)
If I manually tried to change a tag on all of my files, I'd be prompted before it happens.

Creating a backup before a change over X number of files seems like a good idea.
But Media Center doesn't even make daily backups yet, so I'm not hopeful there.
 
And restoring backups is a pain since thumbnails need to be rebuilt every time.

[JimH]

The problem with computers is that they do exactly what you tell them to do.

[6233638]

The problem with computers is that they do exactly what you tell them to do.

Which is why programs usually ask you to confirm if you're about to do a potentially destructive thing.