INTERACT FORUM
More => Old Versions => Media Center 14 (Development Ended) => Topic started by: jolo on September 30, 2009, 12:18:42 am
-
I have a silly question. ?
I save my audio collection in two open source formats:
- FLAC (losless)
- OGG Vorbis (Lossy - but sound great)
So I initially backup my CD, DVD or other media type, to FLAC first.
I have analyze when ripping on, make sure that the Tags are what I want them to be, as well as have Normalize on (I am not sure that does anything for me).
I would like the audio maniacs of this forum to share their thoughts with me.
Then I create a backup of the same audio in Ogg Vorbis (q6 if anyone cares)
I would like to know if there is any audio quality difference if I create my Ogg Vorbis files
- Buy doing another rip directly from the source, that is on media, like I just did with my "Rip and FLAC"
- Or put my media away, and just convert the newly created FLAC files to Ogg Vorvis, rather than re-rip ?
Thanks in advance. ;)
-
Just wanted to note that your FLAC's aren't 100% lossless if you are normalizing the files.
If you don't use that option then there will be absolutely no difference between converting FLAC > Ogg compared CD > Ogg, as long as you're using the same options.
-
While normalizing the files is technically breaking the bit-perfect "losslessness" of the FLAC compression, it should NOT actually impact the quality of the files at all, though... So long as the normalization routine is implemented properly. All normalizing does is shift the dynamic range of a given file to make the loudest part of the wave equal to the maximum possible loudness (instead of leaving unused dynamic range). Normalizing, if implemented correctly, will not compress the dynamic range of a given file, but it can help to make various different recordings made at different times and on different equipment all have the same apparent loudness (while preserving their individual dynamic ranges).
This, obviously, does alter the files, but not in a way that impacts their quality in any way. It just makes them work better in a large collection. I generally turn it off on the rare occasions where I use FLAC files. Not because it impacts quality, but just because it is possible to test the bit-perfectness of the encode without it, and if you're going to do something lossless, why not do it LOSSLESS, you know?
http://en.wikipedia.org/wiki/Audio_normalization
Otherwise, lossless is lossless, so it makes absolutely no difference if you rip the OOG files from the CD or the Flac files.
-
I am sooooooo glad I asked the question. Maybe it wasn't so mindless after all. ?
I have to thank glynor and Dirhael for taking the time to share their expertise and explaining this to me in such a simple, straightforward,
function oriented response.
Yes, I have a large collection. I use normalization, in thinking that when I listen to audio,
I don't want to get a sudden change in volume when listening to my COWON D2 portable media player,
While I have some FLAC on my COWON, 90% of the audio on it is in Ogg Vorbis format.
When ripping from source to FLAC and setting normalization on,
I am creating FLAC files that are not loseless.
Then by encoding the FLAC to OGG (where I have normalization set again),
I might be creating some additional distortion, and I am using "compromised" FLAC files,
that have lost their "loselessness".
Is this somewhat analogous to re-encoding audio that has already been encoded to a lossy format ?
Would this make sense:
- Encode the source to FLAC, with normalization off
- If I choose, encoding from FLAC or the source, to Ogg Vorbis, with normalization on, would do the trick about not having
sudden changes in volume when listing in the car, or walking around and listening with my COWON. - Also, by doing it this way, that is creating FLAC, with Normalization off, from the source audio,
it would leave me with a digital archive of the source that is virtually identical to the original source.
PLEASE let me know if I have an accurate understanding of your wonderful replies.
This forum is one of the reasons that I have been a customer of J. Rivers for so long.
Jon
-
I was reading how some of the replay-gain works with some other apps, when backing up a CD to FLAC.
First thing, when ripping from CD to FLAC:
- MC first will rip the CD audo files to a raw wave file ?
- Then the WAV files are encoded to FLAC
- Then the WAV files that were created are deleted (that is if I make sure that the option to delete those are set)
- If Normalization is set (let us say, 98%), for this process, the actual FLAC files created are still lossless as if I didn't check normalization except that
- There is a code written, somewhere in an header area of the audio file, that some compatible audio players can use play at the same volume.
- The audio file itself, the quality, fidelity, has not been changed at all. It is still the same as any lossless FLAC file and play as well as the original
- The file that I have backed up to FLAC from a CD, and have normalization set, will sound exactly the same, when played on MC, as a
file that I have ripped to FLAC, with normalization off, If I go to the DSP studio and uncheck Volume Leveling ?
- Therefore, in reality, setting normalization on, when ripping from CD to a backup in FLAC format, has NO effect on the audio the is
written really has is still lossless, as it would be if I checked normalization.
What do you think? PLEASE correct me, if my understanding is wrong.
This is the understanding that I have just read about, from another encoder.
Wouldn't this also be true if I used MC to analyze the file, that the audio file itself, is not changed at all, but the information is stored, so if I
play it back, on MC and I configure MC to use the information, it will use it. But, the audio file itself is the same ?
Thanks,
Jon
While normalizing the files is technically breaking the bit-perfect "losslessness" of the FLAC compression, it should NOT actually impact the quality of the files at all, though... So long as the normalization routine is implemented properly. All normalizing does is shift the dynamic range of a given file to make the loudest part of the wave equal to the maximum possible loudness (instead of leaving unused dynamic range). Normalizing, if implemented correctly, will not compress the dynamic range of a given file, but it can help to make various different recordings made at different times and on different equipment all have the same apparent loudness (while preserving their individual dynamic ranges).
This, obviously, does alter the files, but not in a way that impacts their quality in any way. It just makes them work better in a large collection. I generally turn it off on the rare occasions where I use FLAC files. Not because it impacts quality, but just because it is possible to test the bit-perfectness of the encode without it, and if you're going to do something lossless, why not do it LOSSLESS, you know?
http://en.wikipedia.org/wiki/Audio_normalization
Otherwise, lossless is lossless, so it makes absolutely no difference if you rip the OOG files from the CD or the Flac files.
-
What do you think? PLEASE correct me, if my understanding is wrong
You are wrong. :)
The normalization process is a "stupid" volume level adjustment that just makes each track to have the same maximum peak level. It does not take the audio content into account anyhow and the perceived average volume levels will vary in an uncontrolled way. Its adjustment is done with DSP before the files are saved and it actually changes the audio content. Its possible effect to the audio quality (other than the change in volume level) is most likely inaudible because it uses high quality DSP, but nevertheless it alters the audio content and cannot be reverted just by changing a flag in the file header. It does not save any kind of header data or tags.
Replay Gain aka Volume Leveling in MC is a different beast. It does not touch the audio content. It analyzes the content and saves the results in the library database and in the file tags (when possible). The analyzer uses a sophisticated algorithm and really tries to imitate the human auditory system. During playback the saved values can be used for playback correction.
-
You are wrong. :)
The normalization process is a "stupid" volume level adjustment that just makes each track to have the same maximum peak level. It does not take the audio content into account anyhow and the perceived average volume levels will vary in an uncontrolled way. Its adjustment is done with DSP before the files are saved and it actually changes the audio content. Its possible effect to the audio quality (other than the change in volume level) is most likely inaudible because it uses high quality DSP, but nevertheless it alters the audio content and cannot be reverted just by changing a flag in the file header. It does not save any kind of header data or tags.
Replay Gain aka Volume Leveling in MC is a different beast. It does not touch the audio content. It analyzes the content and saves the results in the library database and in the file tags (when possible). The analyzer uses a sophisticated algorithm and really tries to imitate the human auditory system. During playback the saved values can be used for playback correction.
Alex is right (of course), though I think that he overstates the possibility that well-implemented normalization will affect the audio "quality" of any track. Computer audio files have a "range" of possible loudness that ranges from 0% to 100% (I'm simplifying here, but it works). However, a particular audio file that comes directly off of a CD may "peak" (the loudest part of the file) at 60%, while another peaks at 99%. What normalizing does is really quite simple... Basically, if you set normalizing to 98% (a common setting) it will scan through each input file and modify the output file by making the peak = 98% "loudness" and then shifting the remainder of the loudness of the file relatively.
So, for our file that peaked at 60%... Say that the loudest split second was 60% and the quietest split second was 19%. It would shift it to 98% - 57% (19% + 38% shift). For our file that peaked at 99%, say it was 99% - 32%, then it would be simply shifted down by one percent to 98% - 31%.
The one instance where this can impact perceived quality is with "clipping". Basically, say you have a file that is mastered perfectly (the loudest portion of the file is 100% and the quietest is 0.00001%), and then you normalize this to 98%. The problem is that at the bottom of the scale, you'll have shifted the quietest 2% "points" down below zero. The quietest portion of the song would now be -1.99999%, and effectively erased! This would be a real problem if there were lots of "perfectly" mastered tracks.
However, this never, ever, ever happens for two reasons. There is, unfortunately, a "loudness war (http://en.wikipedia.org/wiki/Loudness_war)" with most commercial music. There have been studies that have shown that on the radio, tracks that average "louder" tend to be more popular, and tend to sell better, while the converse is true for quieter tracks. So, commercial recordings have been slowly inching upwards on the percentage scale to the point where for most CDs, the dynamic range is extremely compressed. So, for your average song, the "peak" is at say 97% and the "low" is at 84%. The rest of the range is unused completely. The problem comes when you have one CD where the peak is 97% and the next where the peak is 84%. Both may only use 20-30% of the possible dynamic range, but one will seem much louder than the other. Normalizing fixes this, but can "clip" low-volume sections in extremely rare cases. The second reason this won't ever happen in practice is that a well-implemented normalization routine won't even do this because it will have "clipping protection". Clipping Protection will cause the normalization routine to skip the file or adjust the normalizing percentage if it detects clipping of any kind at the low end of the scale (so it would see that it was going to adjust the bottom of that extreme example I gave down to -1.99999%, and would then skip the file).
Now, can any human being actually hear that bottom 2% that might possibly get clipped off in the vary rare occasion that some old classical recording actually does use the CD's full dynamic range (and you were using a dumb normalization routine with no clipping protection)? No. Absolutely not. If some audiophile tells you they can, make them prove it with a true, blind listening test. It is psychological. However, fair is fair and lossless should really be lossless, so I would recommend against normalizing when ripping to FLAC. If you are going to go through all the hassle of ripping to a lossless format, you might as well really have a completely lossless file and not even risk clipping the files even in the incredibly rare one-in-a-million chance that it could happen.
As Alex indicated, MC's Replay Gain (Volume Leveling) works differently. It applies the changes on the fly and does not impact the audio waveform written to the file.
Okay, now that we've discussed what this is in detail... What should you do?
I think you've come up with a very good compromise:
1. Rip to FLAC with Normalization turned off. If you rip in secure mode (and you might as well if you're ripping to FLAC), these files will be bit-perfect (meaning when you play them back they will be identical in every way to the audio file on the original CD, at least until it gets to the DAC in your computer).
2. Use Replay Gain if desired when playing these FLAC files back on your computer. I recommend Album Based, rather than track based, which will preserve the relative dynamic range of the entire album (important for some well-mastered works, such as those by Nine Inch Nails and The Beatles, for example).
3. If your handheld player does not support an on-the-fly normalization/replay type of feature (the iPod and Sansa does, I don't know about the Cowon players), then enable Normalization when you encode to OGG for handheld use. That way you will protect your eardrums from being blasted out when it switches tracks on you while you run at the gym or whatever.
-
So, for our file that peaked at 60%... Say that the loudest split second was 60% and the quietest split second was 19%. It would shift it to 98% - 57% (19% + 38% shift). For our file that peaked at 99%, say it was 99% - 32%, then it would be simply shifted down by one percent to 98% - 31%.
Just to get very nerdy and explain a little further... With the examples I cited here, the change really is still "lossless", depending on how you look at the word lossless. If you imagine the sound recording as a visual wave file, all you've done is shifted the wave in "height" on the scale (the 99% one down by 1% and the 60% one up by 38%). The wave "pattern" itself has NOT changed in shape (the peaks and the valleys are all identical, relative to each other). And, if you later "de-normalize them" (remember how much "height" you added to or subtracted from the wave file and then reverse that change), they would be again completely identical to the original recording.
The actual information captured by the recording (the shape of the wave) has not changed. It's kind of like how if you subtract 6-4 you get 2. If you add 100 to both numbers and subtract them, you still get 2 (106-104=2), so you haven't really changed anything, so long as you do it equally to both numbers.
One could certainly make the same argument that the very act of converting to FLAC alters the files (it "zips" it into a compressed FLAC container). It would be a DUMB argument, but you could make it all the same. The only difference is that FLAC is designed to automatically give you the same output on decompress, while undoing the normalization would take a bunch of manual work (and extremely good record keeping).
It IS possible that some software (perhaps EAC) automatically tag the FLAC files with the amount of normalization added, in order to allow you to "de-normalize" them later on. However, no true normalization routine would be implemented completely in the tags. The wave file itself is actually modified. Otherwise, it would be called "Replay Gain" (which is essentially a smarter version of the same thing that is done on the fly, and is done so with a model of what the human ear actually hears, rather than just a brute-force "simple math" method).
-
Just to get very nerdy and explain a little further
glynor, get help now. Before it's too late.
-
I hope it's too late. I appreciate his explanations of things that would otherwise make my head explode. ;)
-
one problem with normalizing as far as i know, is that it is done on a file basis, so when you are listening to a clasical or concept album, or even at a live album, the result can be a bit disappointing, or even making things sound very out of place. soft pasages get raised in volume to much, public starts to clap suddenly much louder.. the same is true for replay gain, but album gain is your friend then...
:)
gab
-
one problem with normalizing as far as i know, is that it is done on a file basis, so when you are listening to a clasical or concept album, or even at a live album, the result can be a bit disappointing, or even making things sound very out of place. soft pasages get raised in volume to much, public starts to clap suddenly much louder.. the same is true for replay gain, but album gain is your friend then...
This is absolutely a HUGE issue with doing it at the file level as well, of course. Good point, Gappie!
-
Is there a method or program that would volume level FLAC files much the same way MP3Gain works on MP3 files? (For those not familiar with MP3 Gain, the program calculates replay gain values, but applies the change to the MP3 file itself.)
I don't use normalization when ripping, but would like to make a copy of a diverse group of FLAC files that would play back at similar volume levels. These files would be used as input for a program that can create a DVD-A disk for my car. I've noticed on a mix of songs that the volume changes between tracks can be dramatic upon playback. There are no options in the DVD-A creation program to normalize the output, so I am trying to feed it volume leveled files.
I was hoping to find a program called FLACgain that worked like MP3Gain, but couldn't find anything like that. I also looked to see if MC had an option to copy/convert files to a location and apply the replay gain values, but couldn't find anything that would do the job.
-
Glynor,
I just think you set a fantastic way of handling music/audio files. It's perfect.
- I keeps FLAC, in its most pristine, lossless form, which is perfect for archiving backups. The audio will be off any media, which makes it so much easier to store and re-use. With FLAC being creating, without any type of editing, altering and as a exact copy of the "raw" for or source format, it is great
- Then, with the perfect copy of the backup of the source, in a digital format, it makes it easy to do whatever one wants, while keeping the new "source" FLAC formatted audio unchanged. If a re-encode to Ogg Format is desired, no problem, it can always be done from the FLAC source file.
- This allows the FLAC as source audio file, to be one, where I can not be concerned with the various ways that some encoders work. Simple.
Glynor, just one item more, sorry, but I am learning so much and I hope this string will be of value to others. Thank you to everyone that has contributed.
If the source of the backup is a CD, that is in perfect condition and is wiped with a micro-fiber cloth before being placed in my CD/DVD ROM,
- Do you see why there is any reason to use a more complex product like EAC over MC ?
Does EAC produce output that really is functionally superior in anyway to MC ? - I also don't see a need to rip (like I used to), first to WAV, then to FLAC and Ogg Vorbis.
I assume that first MC converts the CDA to WAV, then encodes the WAV, that is in a workarea and/or RAM, to FLAC. The WAV that is first created should be of the same quality as a WAV file produced by EAC OR MC - Do you see a reason for the backing up to FLAC, in secure mode ?
- Is it really any more reliable to create the backup at a slower speed than leaving it to MC, with the maximum setting.
I have been slowing it down to 8x, for "paranoia: reasons. - From my experience from ripping, burning and encoding over the years, that it is best to do,
after a PC has been, re-boot. (I also will execute Ccleaner, before I re-boot).
That a re-boot gets rid of any rumblings of possible garbage from any software failures during the session,
or anything else that might be hanging out in RAM. In my experience, it is some crud hanging around in RAM, from a active session,
that has produced more "coasters" and failed rips than anything else - In general, when backing up, encoding or burning, it is a good idea to try not do any other processes at the same time.
Even with a PC that has lots of RAM and a multi-processor CPU - I think the importance of using EAC is greatly over-rated. Much more important is the condition of the source, a quick cleaning of the media,
a CD/DVD Rom that is clean, that other processes not done, or at a minimum, the backup/encoding/burning to be done,
after a re-boot (make sure that only what is needed is running at startup), media is a rip, than having to use complex software. Of course it is important that the software is "battle tested", and has been around for a while.
I think you've come up with a very good compromise:
1. Rip to FLAC with Normalization turned off. If you rip in secure mode (and you might as well if you're ripping to FLAC), these files will be bit-perfect (meaning when you play them back they will be identical in every way to the audio file on the original CD, at least until it gets to the DAC in your computer).
2. Use Replay Gain if desired when playing these FLAC files back on your computer. I recommend Album Based, rather than track based, which will preserve the relative dynamic range of the entire album (important for some well-mastered works, such as those by Nine Inch Nails and The Beatles, for example).
3. If your handheld player does not support an on-the-fly normalization/replay type of feature (the iPod and Sansa does, I don't know about the Cowon players), then enable Normalization when you encode to OGG for handheld use. That way you will protect your eardrums from being blasted out when it switches tracks on you while you run at the gym or whatever.
-
It is just my opinion, but I will certainly answer...
1. Ripping with MC vs. EAC: The only reason I see to pull out EAC is if MC's CD Database doesn't find your disc (EAC uses the Gracenote database, which has some discs that YADB does not). Quality wise, they are identical. There may be some features of EAC that some people like better, but a 100% secure rip is a 100% secure rip, regardless of what software does it. I am, by no means, an EAC expert, so someone correct me here if I'm wrong. I do know that Matt and Co. put a LOT of work into the ripping engine of MC to make it top-notch.
2. Ripping to WAV first: That's just silly. There is no need. Rip directly to FLAC using MC. I'm not sure if MC uses WAV internally in the FLAC plugin or not currently, but it doesn't matter. FLAC is absolutely 100% equivalent to WAV in quality. It is no different than putting a WAV file into a ZIP file (only it is more efficient at compression). Lossless means there is absolutely, positively, without-a-doubt ZERO data lost during the transition.
In fact, it could be argued that ripping to WAV first and then transcoding to FLAC could possibly open you up to data corruption, simply because it is one extra step. More steps = more complexity = more chances for failure. Keep It Simple Stupid.
3. Ripping to FLAC using Secure Mode: Yes, there is a good reason to do this. All digital data written to spinning disks (including those of the optical variety) contains errors. Furthermore, when you are using a modern DVD-RW drive to read a CD, it is actually being read at many, many, many times the speed that the standard was originally designed for, which can also introduce read errors. CDs do contain error correction designed to deal with these issues, but the algorithms are designed to favor speed over accuracy (and allow "acceptable" data loss). One way to combat this is to rip the disc at a lower read speed (slowing down to 8x as you suggested). However, this is not guaranteed to avoid errors (especially with a damaged or badly pressed disc), it just makes them less likely. More importantly, it wastes time on the vast majority of discs where reading at 20x or 30x would be just fine. Secure Mode is the answer. It rips at a variable speed, slowing down as needed to get a PERFECT read, and then it VERIFIES that the read was 100% perfect. Turn logging on to have it spit out a file to confirm this (you can delete the files later). If it isn't (which can happen with a damaged disc), then it will notify you in the log and give you a percentage estimate of the rip quality. Ripping in Secure Mode is the only way to ensure that you have a 100% perfect digital copy of what exists on the disc.
So, even though the FLAC compression is perfect and does not lose any data at all, that doesn't help you if the data coming out of the Optical Drive is incorrect. FLAC can't fix problems that happen in hardware inside the drive. Ripping in Secure Mode prevents this kind of data-loss or corruption.
It saves some time to turn off Secure Mode, but it only saves time because it doesn't care about "minor" errors (and it really doesn't even check to see if the errors are really minor, it just trusts the error correction hardware built into the optical drive). Now, if you are encoding to a lossy format like MP3, then any minor error is going to be obfuscated by the lossy compression scheme, so it doesn't really matter. If you are going through the trouble of ripping to FLAC and maintaining a lossless archive, then you NEED to be using Secure Mode.
4. Slower Speed on Rips: Absolutely not necessary, and often a waste of time. Use Secure Mode instead.
5. Rebooting and using CCleaner: If you really need to do this, then something is wrong with your system. That said, I run CCleaner every single day on all of my systems via a scheduled task. That's just good maintenance and good security practice. Windows XP likes a reboot every once in a while, but you certainly shouldn't need to do this now with modern hardware and software before ripping every single time... That's mid-1990's era paranoia there. If you have a hung process during a burn or a rip, then you should certainly reboot before continuing, but this should be EXTREMELY rare. If not, then you have some other issues with your system (corrupted Windows install, ASPI drivers, or faulty hardware). Ripping to Secure Mode will set your mind at ease that the rips are perfect. If they aren't, then you can set about cache cleaning, rebooting, disc-cleaning, and the rest. Unless you are hitting a hardware or software issue, you should find that most of your Secure Rips with non-damaged discs will go smoothly and will be 100%.