I'm just getting towards the end of the horrible task of ripping all my music from CD to flac. I did all of this without any normalisation, but I'm beginning to wonder if this was a mistake. What exactly does the normalisation process do? Can it be done "post-rip" by a Linux tool (my server runs Debian Testing)? Do you lose quality by doing this? It's a bit of a pain to have tracks play at significantly different volume levels when create playlists from different albums, but I'm prepared to put up with this if the alternative is loss of quality.
-
Some people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus. -
Normalising FLAC files
The preferred method for doing this is ReplayGain, which stores gain
correction values for the track on its own and for the track as part
of its album. Unlike regular normalization this doesn't touch your
audio data at all - it's only applied at playback time.
A quick apt-cache search tells me that crip should be able to add the
relevant info under linux.
AFAIK the sb doesn't support RG yet, though. An enhancement bug has
been filed under http://bugs.slimdevices.com/show_bug.cgi?id=1311
C.
-
Thanks for the information. I've had a quick look at crip, and it looks like it relies on doing the ripping there and then. Unfortunately, I've just about finished doing my ripping so need something that can read through already encoded flac files, calculate replay gain information for them and then write it into the files. If anyone knows a tool that can do this, I'd be very grateful to hear about it!Some people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
flac replaygain can be applied serverside, as long as you don't mind sending wav to the squeezebox.
Here's my slimserver-convert.conf file:
flc wav * *
[flac] -dcs --force-raw-format --endian=little --sign=signed --apply-replaygain-which-is-not-lossless=a --skip=$START$ --until=$END$ $FILE$
flc mp3 * *
[flac] -dcs --apply-replaygain-which-is-not-lossless=a --skip=$START$ --until=$END$ $FILE$ | [lame] --resample 44100 --silent -q 9 -b $BITRATE$ - -
metaflac --add-replay-gain *.flac will add the replaygain tags to an album's worth of flac files. If you are fortunate to have 1 album per directory it is pretty straightforward to write a script to recursively add replaygain correctly to your albums.Comment
-
Aha! I hadn't spotted that metaflac would do that for me. Thanks for pointing that out! I assume that replay gain for FLAC will be added to the SB2 at some point in the future. Does anyone have any further information on that?Originally posted by jthSome people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
My music is all stored in a directory for each album, so I guess I can simply do the following:
---
#!/bin/sh
basedir=${1:-.}
IFS="
"
for dir in `find $basedir -type d`; do
metaflac --add-replay-gain "$dir/*.flac"
done
---
This would work, but would output errors for loads of directories that only contain other directories. Can anyone suggest how to only call metaflac for directories containing flac files?Some people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
A lazy person might just redirect stderr to /dev/null, or you might try something like [ -f "$dir/*.flac" ] && metaflac --add-replay-gain "$dir/*.flac"Comment
-
I don't think this would work. If you put quotes around the *, it doesn't expand. If you remove them, it expands and test complains that there are too many arguments. I haven't yet tried this though, so I could be wrong.Some people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
Yes, you are right, I had forgotten that file test operators only work on single files. Perhaps something like this:
ls $dir/*.flac >/dev/null 2>&1 && metaflac --add-replay-gain $dir/*.flac
As with any sort of this kind of script, I'd recommend duplicating a portion of your directory tree and testing against that to ensure correct behavior before running against your whole collection.Comment
-
Ooh, nice hack! The joys of UNIX shell scripting. :-) That said, I had the misfortune to have to right some Win95 batch files the other day. You have to use GOTOs for goodness sake!Some people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
Might I humbly suggest
I was recently in an identical situation to you, I'd archived my whole collection and hadn't used ReplayGain. If you are looking for the best solution to this problem, I'd suggest using foobar2000:
Simply add all your music to the play view, select all, right click and select ReplayGain > Scan Selection as Multiple Albums. Provided that your metatags are properly set (especially the album tag in this case), foobar will tag everything in your library with both AlbumGain and TrackGain.
It took about 25 minutes for my 600 disc collection.Comment
-
Re: Normalising FLAC files
Max.spicer wrote:
>I'm just getting towards the end of the horrible task of ripping all my
>music from CD to flac. I did all of this without any normalisation, but
>I'm beginning to wonder if this was a mistake. What exactly does the
>normalisation process do?
Normalization is ensuring that the maximum value of the digital signal
is as high as allowed by the format. (This is normally called 0 dB full
scale)
For example, if your song never got louder than -3 dBFS,
you could 'normalize' it by adding 3 dB to each value
to make sure that it is full scale. (Actually, you multiple all values
by 2, which is how you make something 3 dB louder)
Many extraction utilities will tell you the highest signal encountered
during the extract (aka rip, but that usually means extract and
compress).
> Can it be done "post-rip" by a Linux tool (my server runs Debian )?
Sure, you can, there are other posts that tell you how to do it.
>Do you lose quality by doing this?
Yes, you lose quality. And the point of using a lossless
compression such as FLAC is that you can recreate the
original signal, bit for bit, if you want to.
If you normalize it, or do any other signal processing (compress, EQ,
etc.) then you no longer can restore it to the original.
This flies in the face of why you would want to use FLAC in
the first place.
(Of course, you could keep both the un-messed with version and
the normalized/EQ/compressed version for only twice the disk space,
and then you would not lose anything in the original.)
The specifics on what you lose tend to get complicated.
As a minimum, you lose the dithering that the mastering house
did on the original recording.
If you are doing critical listening, I'd strongly suggest
that you not touch the original data. If it is for background
music, I'd make a second copy with a lossy compression
and do signal compression, and EQ for "loudness contour"
while you are at it.
You can automate it all with a couple of shell scripts.
--
Pat
Comment
-
By the sounds of it though, adding Replay Gain metadata gives me the best of both worlds. Thanks for the detailed description.
MaxSome people think the title of this song is irrelevant,
but it's not irrelevant - it's a hippopotamus.Comment
-
oh dear....!
Originally posted by Pat Farrell
I have started ripping my CDs to FLAC for use with my squeezebox and am using dbpowerAMP. However, I have had the volume normalisation turned on!! I presume this means:
1) I have been altering the data itself (not just the metadata)
2) The FLAC files are not strictly lossless so I cannot get back to the original WAV.
Can anyone confirm the above 2 comments please? I am thinking I'll need to start the rip process again using ReplayGain....ouch!
JimmyComment
-
This is correct, strictly speaking, but don't panic. Yes, you are altering the data, by multiplying it by a constant. Yes, this is not strictly lossless because the results are rounded off (to a mere 16 bits, or about 5 decimal digits), so that dividing by the same constant will not necessarily recover precisely the same value. (In Pat's example, multiplying by 2, it will, in fact; but you might be multiplying by 2.0001 instead.) This is not the same kind of data loss you get compressing and decompressing a file with a lossy algorithm.Originally posted by jimmy
Anyway, if you use ReplayGain, you do the same multiplication when you play the file, so you are not going to hear anything different. The difference, such as it is, would happen if you tried to un-normalize the file back to the original for some reason and then processed it again.
So, yes, if you are planning to rip the disks and then throw them away, and then try to burn replacements at the original volume, and then rip those and renormalize them to a *different* volume, you had better get cracking on reripping now. Or, you could spend your time listening to what you have, and do all that later, after you think up a reason why you would need to.Last edited by tom permutt; 2006-01-17, 18:29.Comment
Comment