Hi everyone. I just discovered the Empeg and this board from the review at Anandtech. The Empeg is about the coolest thing I've ever seen so I decided that I had to have one. I'm tired of having the same 10 CD's in my car for months at a time.

But I've never done much with MP3's other then download a few songs from Napster. I've never ripped a CD to MP3 before. This is going to take a long time to rip 200 CD's and I *really* don't want to to do it more than once. Can you guys give me some general tips/suggestions so I'm not smacking myself later when I realize I could have done it better.

It looks like AudioCatalyst is the tool to use. I don't mind paying the $30 for it. I also know that my drive supports DAE at about 8x.

What about bitrates and VBR? Is 128K really CD quality? I consider myself an audiophile though my car system isn't that great. So I am picky about sound quality up to the resolving ability of the system in my car.

TIA for any help!

-Dylan


Queue# 15969

I used to use audio catalyst but everytime I have to setup my computer when I would reinstall audio catalyst it was a pain getting it to work because it requires aspi

I have sience found AltoMP3 Maker it does not require aspi and has all the features that audio catalyst has (as far as I know) http://www.yuansoft.com/ is the homepage to altomp3
it was 20.00

It looks like AudioCatalyst is the tool to use. I don't mind paying the $30 for it.
Is 128K really CD quality?

I agree to your first statement: am using (have used) AC to fill just over 60% of my Mk2's capacity (2852 tracks /some 250 CD's I think and am happy with its performance. It is easy to use and has sufficient settings to cope with most of my requirements. I especially like its VBR capabilities that *really* seem to be able to save disk-space while maintaining a pretty good quality. Started out with medium/high settings, when I first got my Mk1. Have moved to 'high quality' ripping, now I have the Mk2. At the high setting, it all sounds a lot smoother. I'm not sure as to why I'm hearing a difference. It could be that the Mk2 is so much more critical than the Mk1, which I dout. It could also be that you develop an ear for the artifacts that creep into MP3 encoding: at first it all sounds pretty impressive, but over time you start to learn what to listen for. Forget about 128, unless you need to cramp a lot of info into a small space. IMHO it is not suitable for music.

Anyhow: AC / high / VBR does it for me (and many others on this board).


going to take a long time to rip 200 CD's and I *really* don't want to to do it more than once.
My advise: use AC, and use CDDB to retrieve raw track/album info. After ripping, review theID3 tags and make sure they are accurate and complete. The empeg software is pretty powerful, but needs correct/accurate data. For a little bit of tweaking of tag info, you can use AC. When tags are seriously out or inconsistent, you'll need a more powerful tag editor. I'm very happy with Tag&Rename.

Good Luck

Henno
mk2 6 nr 6

I've been using MusicMatch since v3.something, and I've been very pleased with it. Take a look at www.musicmatch.com.

The program has a lot of features I don't use, but it great for ripping.

In the past I used 160Kbps, now i'm using VBR at 75%. (equals to about 192kbps higher when needed.) I think this is an OK setting.


TommyE

Greetings!

I personally used Sonic Foundry's "Siren" to do the encoding. I used 128kbpsVBR. The settings were for highest quality encode and 100% VBR. I have not noticed any problems with the recordings I have made, but I am still listening through my local sound card - once I get the empeg, I may need to re-rip (I have heard that the quality of the empeg can really show up the defects in encoding schemes...). This concept does not thrill me - it took me over 2 months to rip my CD collection.

What I would recommend, rather than trying one specific encoding sceme / product, select 3 key songs of various songs / artists / styles. Use this as a test case. Then use the trial versions of all of the products you have heard mentioned to rip the same 3 songs, at different rates. Find what sounds best to you.

You may also want to try to burn them back to a CD, if you have the software / hardware. This way, you could see how they uncompress to standard WAV/Redbook, and you could also compare them on a higher end audio system, looking for artifacts.

Paul G.
Q# 15189
Status: In queue for a green 36GB Mk2

I believe there is info on this in the FAQ.
I use AC and it has performed very well for me. It's easy to use and it's more advanced features are simple to figure out.

I just went with 128 instead of VBR, but many of the empeg owners on the board prefer VBR. The whole process is quite simple and you'll have no trouble doing this. Just make sure your naming convention is consistent, and I would heavily recommend naming your files with the track number in them and before the track title. That way they will be in order in explorer, so when you drag the folders over to the emplode window, your playlist is created with all the tracks in order.

Happy ripping!

(ps-it's good to see that not all the Anandtech readers are turned off by the empeg. hey guys, looks like one of them does "get it"!)

DiGNAN

Thanks everyone for the replies.

I did an experiment last night like Paul suggested. I encoded three songs at 7 different compression rates using the XING encoder in AudioCatalyst. I used fixed rates of 128, 160, 192, and 224 and variable rates of normal, normal/high, and high. I burned them back to CD using Easy CD Creator and compared the results on my main audio system (which I think is a pretty revealing system).

My first reaction was surprise at how good 128K sounded. The differences between 128K and the original were more subtle then I expected. By the time I moved up to 192K the differences were extremely subtle. All of my 224K recordings skipped so either XING messed up when encoding or Easy CD Creator couldn't decode it correctly. I suspect the latter.

The VBR recordings all sounded better then the FBR recordings that took similar space. Normal was around the same size as 128K, Normal/High compared to 160K and High compared to 192K. I'd say that VBR Normal/High was pretty close to FBR 192K in terms of quality but uses considerably less space. I could still hear a difference between Normal/High and High on my home system but it was very, very subtle and I'm almost positive that I won't be able to tell the difference in my car. In fact, I'd probably be happy with Normal in my car.

So I think VBR Normal/High provides the best quality/space tradeoff using the XING encoder. Now that I've got a feel for the different levels of MP3 compression and what I like, I'll play with the other encoders recommended in this thread and see how they compare in terms of features and sound quality.

Oh yeah, one bitch towards XING. I had to pull down a pirated version of AudioCatalyst just to be able to try it out. Their demo version only allows encoding at 128K and doesn't let you choose which song! Now I'm all for people getting paid for the software they write and I will pay for AudioCatalyst if I choose to continue using it. But if you are going to cripple your shareware don't do it in such a way that prevents people from being able to evaluate it! Grrrrrrrrrrr

-Dylan


Queue# 15969

Greetings!

Glad the test worked out well. One other thing - whatever encoder you use, I strongly recommend something with CDDB that can autopopulate the ID3 tags. You will still have to clean them up later, but this will lessen the amount of bulk work you need to do.

Paul G.
Q# 15189
Status: In queue for a green 36GB Mk2

Greetings!

A thought - for all those people still encoding. Everyone on the board has their own preferred software package. How about a comparison / showdown? People can encode one pre-determined track from a specific artist (I think Rush or Led Zeppelin has been on almost everyone's posts so far). It should be done at a specific bit rate / VBR setting. These files can then be compared to see what software gives the best results. Anyone interested?

Paul G.
Q# 15189
Status: In queue for a green 36GB Mk2

I strongly recommend something with CDDB that can autopopulate the ID3 tags

Oh don't worry, Audiocatalyst does that perfectly.

ps-glad I could help Dylan. I was pleasantly suprised myself by how customizeable AC was when it let me choose how to name it file and in what order to do it in!

DiGNAN

I'd be up for something like that if someone told me what I needed in order to do it. In what way would we compare the results?

My personal pick that is fairly common would be for Zep, of course. Then again I might be biased because I don't have any Rush

And lord knows I've been listening to Zep constantly lately. I've just had II, III, IV, Houses of the Holy, and Physical Graffiti running non-stop at my computer and in the car.

Just can't get enough Zeppelin!!!

DiGNAN

I found the FAQ topics on ripping and naming. I had been through the FAQ before I posted but I must have skipped right over these because I was so eager to learn more about the Empeg.

I read the encoder comparisons at r3mix. That guy really blasts XING and hypes up LAME. So I tried out LAME and a ripper called Exact Audio Copy (EAC). EAC claims to do error detection to guarantee the best rip possible. The software is a little bit rough but still pretty decent for freeware. The problem is that the EAC/LAME takes 4 times longer than AC/XING to rip and encode a CD. I used the recommended encoding settings from r3mix and the file sizes were about the same as XING's VBR Normal/High setting. I didn't compare them for sound quality because I decided that it didn't matter. I'd already compared XING to the original and even if LAME generated a perfect copy it wouldn't be enough improvement to make it worth the added encoding time. At 50 minutes for a full CD I could probably only average a couple a day unless I want to become a CD feeding monkey slave to my computer. So I'll stick with AC/XING because it's fast and I like the interface.

I did try out the other packages recommended in this thread but preferred AC. Thanks for the suggestions, though.

I have a tip for others that may be reading this. Maybe it should be obvious but I'd already ripped a few discs before I realized it. The artist fields from CDDB are all over the place. Some are First Last while others are Last, First. Many groups have "The" in the front. I would guess that it's important for easy searching with Empeg to be consistent with ordering of names and to not start with The. I'll have to retag a couple of my rips.

-Dylan


Queue# 15969

The problem is that the EAC/LAME takes 4 times longer than AC/XING to rip and encode a CD. I used the recommended encoding settings from r3mix and the file sizes were about the same as XING's VBR Normal/High setting. I didn't compare them for sound quality because I decided that it didn't matter.

Look at it this way: you rip and encode a CD once; you'll listen to it many many times. It's definitely worth taking the time to do it properly (that's what you were asking for in the first place).

Ripping a CD badly produces very noticable pops and clicks. I use cdparanoia under Linux (similar in functionality to EAC), it tells me when it detects an error in the data stream produced by the CDROM drive. I don't think I've ever ripped a track without at least 2-3 corrected errors in it. A less paranoid ripper would have left pops in their place.

Differences in the quality of the encoding would be harder to notice, but if you can notice them, I think it's definitely worth going with the better one, even if it takes longer. At least for your favourite CDs

Borislav

Edited by borislav on 25/9/00 08:07 AM.

Great idea! One suggestion: we should start with the same set of WAV files to eliminate errors introduced by bad rips (unless you want to compare ripping utilities but that's an orthogonal issue). Also, you can't mandate a specific VBR setting since every encoder has a different scale (e.g. LAME uses a 0-9 scale).

Borislav

Heck, we could do both at the same time! Of course, it wouldn't take that long for those of us who use AC, because it does both at the same time very quickly

Anyway, I think that reminder on the artist field is a very good one. I've experienced much of the same stuff, and I know I missed it on alot of my files. But since I don't use the search all that much...ah well.

Anyway, happy ripping.

DiGNAN

even if LAME generated a perfect copy it wouldn't be enough improvement to make it worth the added encoding time. At 50 minutes for a full CD I could probably only average a couple a day unless I want to become a CD feeding monkey slave to my computer.

Each to his own, but to my mind having a good-quality copy outweighed the chore of the added encoding time. So I became a CD feeding monkey slave, at least at work: I brought in 15 or so CDs each morning, ripped them during the day without encoding them (changing the CD whenever I noticed one had finished), and then set a batch encoding job going each night so they were all done by morning. (Of course, it helped that I had shedloads of disc space on my work PC.)

At 15 CDs per working day it didn't take long to do my whole collection. Doing the encoding separately and overnight stopped the PC from being too sluggish when I was trying to do real work on it.

Peter

I've mentioned it here before, but I'm a big fan of the EAC/Lame pair. As was stated above, you only (hopefuly) rip a CD once, but listen to it many times.

EAC will report the location of a suspicious part in a track. I have actually then listened to the track, and can (usually) hear the crack, pop, etc that was mentioned. I usually try re-ripping just that track, and some of the time, it's successful. Sometimes, the disc is just too damaged at that part to rip cleanly.

If you've read the r3mix reviews, you know that AudioCatalyst completely kills anything above 16KHz. Some people can't hear this high, but many can.

VBR is IMHO better than CBR for the very reason it was created. I rip all of my CDs with a minimum bitrate of 96k, and a max of 320k. This way if it's a not very demanding section of music (or silence), it doesn't use as much space (granted only 96k instead of 128k or whatever CBR we're comparing it to.) If it's a demanding piece of music, it sounds much better because it gets more bits allocated to it.

For the last year or so, I used AudioCatalyst because it is easy. Stick the CD in, and click a button.

I'm now in the process of re-ripping everything using EAC/Lame, because I can hear the difference. I've spent $1400 on the empeg, and another who knows how much on an amp, speakers, wiring, crossover, etc. (I do know, but I don't like to think about it. ) The last thing I want to do is skimp on the recording and have all of this wonderful hardware sound bad. (edit: It's for this very same reason I support Doug in his crusade for subwoofers. Why spend over $2k on everything else and miss that part of the audio spectrum???)

As the saying goes: "If it's worth doing, then it's worth doing right."

-Trevor

-----
Mk 2, Green 12GB 080000349

Edited by trevorp on 25/9/00 04:47 PM.

That's a good idea about using my time at work to rip the CD's and then encode them overnight. But how do you get the ID tag information preserved from the rip to the encode if they are two steps?

I get it to rip to a file called "Artist/Album/nn Track.wav", my encoding script converts that to "Artist/Album/nn Track.mp3", and a second script goes through the results and id3 tags them based on filename.

I have a 300 CD jukebox that I can control programatically with Slink-e from Nirvis. The jukebox has digital output and my soundcard has a digital input so, theoretically, I can rip WAV's from the jukebox without ever going to analog.

Now there's interesting. I've got a Slink-e too, but didn't explore that avenue (a) because it wouldn't do scratch correction like EAC or cdparanoia would, and (b) my sound card hasn't got a digital in.

Presumably, one alternative to Slink-e (which I regard as having been obsoleted by the empeg) would be something based on this technology...

Peter

Damn it, I sold my CDP-CX200 in favor of a Pioneer PDF-1039 which holds 300 discs, but dosen't use the S-link interface. This Slink-E thing looks pretty useful. Damn Sony monopoly.


-Tony
MkII 080000554

That's a good idea about using my time at work to rip the CD's and then encode them overnight. But how do you get the ID tag information preserved from the rip to the encode if they are two steps?

Generally, you don't. Unless the ripper supports some kind of batching option, which I don't know if any of them do.

What you'd want to use is a separate encoder front-end which group-adds the tags for you, such as my Jack program. I wrote jack because I was doing the same thing: Having my computer rip CDs in the background as I worked, then running the command-line encodes overnight.

I recently even modified it so that it has presets for LAME since I was experimenting with that software. (Side note: I'm pretty happy with LAME for now, although I'm not certain whether I can tell the difference between its encoder and the Xing encoder. I'm still on the fence between Xing/AC and LAME.)

My Jack program doesn't access the CDDB. It requires that you type in the song data, but it does its best to make that process as painless as possible (i.e., no Ctrl-V-fests, all logical defaults for hitting the Enter key, easy moving from field to field without the mouse, etc.). In practice, it only takes me a couple minutes to fill in an album's tags. Jack avoids the CDDB on purpose, because I don't trust the CDDB. As was pointed out elsewhere on this thread, the CDDB is filled out by people, and therein lies its problem: The consistency is all over the map. Not to mention that the Year information isn't stored in the CDDB and you have to enter that yourself.

Jack can do a batch of multiple CD encodings in one run, although there is an upper limit (I think it's nine albums although I'm not sure right now). With Jack, if you want to do multiple album rips in one batch, you just save your "track01.wav" "track02.wav" files into different-named subfolders. Then you run jack and feed it each of those folders. It'll let you fill out the tag data for all the tracks of all the albums before committing to the final bulk-encode.

Of course, Jack isn't the only software which works as an encoder front-end. Check out the software library at MP3.COM for more options.

___________
Tony Fabris

The best compromise that I've found for encoding is to use Audiograbber as the front end, and Lame as the encoder.

Audiograbber is the front end that Xing use for AudioCatalyst, and it is certainly the best that I've found. You can find it at http://www.audiograbber.com.

I did try EAC, but found that it was too slow given the number of CDs that I had to encode (over 400). I have found that the combination of a 32x Plextor SCSI CD-Rom drive and AudioGrabber gives equal quality. I have never encountered a single pop or click in any track grabbed with this combination, and I've now grabbed my entire CD collection.

On the subject of encoding, AudioGrabber has a great feature which allows you to grab multiple CDs into one directory, whilst preserving the ID3 header information in the WAV header.

You then simply drag and drop all of the WAVs from Explorer onto the AudioGrabber window and it begins encoding them all. The best bit of all is that it creates a directory structure of:

Artist -> Album Name -> Track.mp3

and then deletes the original WAV when it's done encoding.

Using this technique I was able to grab about 40 CDs at a time to WAV, and then simply leave the computer overnight to do the encoding of all of them.

Andy.

Dylan,

That CD jukebox sounds nice, but you need to be aware that you will not get the same results as you would with a more, um, "persistent" program like Exact Audio Copy. Your CD jukebox will indeed stream digital data from the CD player, but it will likely not be as error-free. You may not realize this because your CD player's error correction and error masking system may do a good job most of the time of covering up those errors. So it will be fine to listen to, most of the time; but the data won't be clean, and then you'll be encoding an imperfect copy---and what's the point of that? It might be hard to believe that CD transports are so unreliable when it comes to extracting the data; but I encourage you to read pages like this one to understand the trouble people go to to get "secure" extraction.

Besides, if you use your jukebox in this manner, aren't you still going to have to manually intervene a lot to extract each track individually?

I really want to encourage you to make that initial investment to rip your CDs cleanly and encode them liberally. Disc space is cheap, and ultimately so is your time, since you will be using this MP3 player a lot longer than you will spend encoding your collection. Once you get a good rhythm, you'll be able to rip and encode in the background while you work on other things.


Michael Grant
12GB Green
080000266

I am on the same hunt as many of you...which encoder...what bitrate....what quality settings. This is where I'm at....and still looking for help:

1 - I read the remix review and some others...all seem to point to Lame having the best sound, followed very closely by the Fraunhaufer... Xing having the advantage in terms of speediness.

2 - Most all encoders use a low pass filter around 15-16 kHz...effectively chopping off the highs. Lame is the one exception that allows you to turn this off using the -k option to get full bandwidth. At this time, however, I'm unsure of the complete effects of this manuever. Don't know if it slows down the encoding or adds artifacts. I've been using it though...and crossing my fingers..

3 - While Xing is reported to be way faster, I also don't like the fact that it lops off the highs. But I'm still on the fence about the issue. Perhaps if I was limiting myself to Nomad usage or something...but not with the Empeg which will be playing in car and home system a plenty. Probably worth taking the extra time to use Lame.

4 - Figuring out which settings to use in Lame is something else. The guys that are working on Lame are constantly changing it. There are warnings all over the docs to use VBR mode at own risk since VBR is currently under heavy development. For a while I subscribed the the Lame developer maillist and listened to them chitter chatter about it all. It was all very confusing and I went away having absolutely no idea what the optimal settings would be in Lame...and feeling even that because they have been changing the algorithms over time, what was once the right settings a while ago, may not now be the case. These are the settings for Lame that I have settled on for now, but nervous still about VBR:

lame in_file out_file -V1 -mj -h -b160 -F -k -p

Those settings effectly use quality 1 of VBR mode (whatever that means) with a minium bitrate of 160, forced to that min, with the 16kHz lowpass filter turned off and joint stereo mode. Files end up being average size of 190kb. 1.5MB per minute. I would like to try some experiments where I lower the minimum bitrate a bit to see if it still sounds as good, but with some space savings, but I have a feeling that the space savings would be minimal. I'm also torn on the JOINT vs. non joint stereo modes. Anyone have any experience comparing these two modes? I read in some review that no appreciable difference could be discerned between V0 and V1 quality levels...so I have been using V1. I have not tested V0 to see how much bigger, how much longer or how much better it sounds... Anyone else?

5 - Using Lame with Audiograbber is how I have been doing it too. There are lots of ways to work. You can have each track be turned into MP3 immediately after it is ripped, leaving no trace of a WAV file behind (handy if you're short on disk space), or you can rip a bunch of WAV files (it keeps ID3 info in the WAV file header) and then you simply drag and drop all the WAV files onto Audiograbber and it encodes them using whatever encoder you want to use, with whatever options you want to use. The ID3 info all comes across just great. However I still use DrTag to clean up the tags, set the track number fields, etc. However I am finding less and less that I need to do that as I use Audiograbber properly.

6 - For those of you that don't know it, VBR gives DJ's a hard time (those using MP3's). Its hard or impossible to match beats. I've noticed also that the Empeg sometimes has trouble fast forwarding through a VBR tune. I can live with that compromise though...for hopefully better sound.

7 - Lame does take a long time. Audiograbber seems to be able to rip my CD's at about 20 seconds per 5 minute song. Usually averages around 12x speed while ripping (Plextor 12/4/32). Lame then takes like 3-5 minutes per song to encode. It pretty much encodes at about 1x speed on my Pentium 500...with nothing else happening on the computer and at the settings I mentioned above.

7 - I would REALLY like to see more feedback from people about which encoder and settings they are using. I'm spending so much time doing all this encoding. I really wanna make sure I get it right....

thanks

-steve
sjs@bstage.com

Oh yea...one more question for you all:

Are you guys normalizing when you rip? If so, what settings are you using? Audiograbber has the option of normalizing to a specified percentage if the input WAV is smaller or larger than designated percentages. I'm nervous about tracks that are meant to be quiet... Just wondering what you guys are doing. As of now I think my plan of attack will be to NOT normalize. Later one, as I use my Empeg, certain albums that are bugging me from being too low, I'll re-encode them and use normalization to bring up their level. I guess. What are you guys doing?

-steve
sjs@bstage.com

2 - Most all encoders use a low pass filter around 15-16 kHz...effectively chopping off the highs. Lame is the one exception that allows you to turn this off using the -k option to get full bandwidth. At this time, however, I'm unsure of the complete effects of this manuever. Don't know if it slows down the encoding or adds artifacts. I've been using it though...and crossing my fingers..

I'd be pretty wary of eliminating the low pass filter. There's a reason it's in there. Those who are writing the encoder feel that it needs to be filtered else the artifacts will be too severe. You've got to believe that they know what they're doing. In the case of LAME, the filter is not fixed at 16 KHz but is variable depending on the bitrate. See this bit from the r3mix site.

http://users.belgacom.net/gc247244/critique.htm#PERFECT

-Dylan

I use Cdex http://www.cdex.n3.net it has CDDB and a host of options, I used it to rip about the same amount of CD's. I have also used RazorLame (which uses Lame a most touted encoder by many as being the best) by way of tfabris's suggestion of exposing the tracks on the CD-ROM's as .wav files. RazorLame encodes only and has no CDDB. I find they both work well and have various VBR settings, which keeps the files a little smaller while getting the best quality, the cake and eating it too thing.
If you use RazorLame you will have to enter filenames manually.
For ID Tagging I use MP Tagger http://surf.to/mptagger seems to work great and for multiple entry ID's there's MP3 Tag Studio, I tend not to use it anymore because all of my tags ended up the same with it's multi-tag at once feature and I had to go back and change all of them individually, big pain.:[
Another neat little utility is called MP3 Trim http://www.logicell.com/~mp3trim/ which I use to cut parts I don't want (start/end) from the song and even fade in/out of those songs that have too long a silence.
Well there are many options, too many, good luck.

#090000695 Mk2 BLUE 12Gig

I read a bunch of discussion about the low pass filter on the lame maillist a while back. I can't remember all the specifics exactly though. Setting the lowpass a bit higher might not be a bad idea though...still kinda safe. I wish I could remember why they lop off the top, but I seem to recall that the main reason is to speed up the encoding process and reduce file size. those high frequencies might require more bits...etc... but more importantly, they definitely require more CPU cycles to compress...

Origionally I was debating on this subject as well, but ended up decideing to use Normalaizing. I have it set to Normalize to 98% if peak is less than 90% or greater then 100%. This effectivly will only normalize if it's less then 90%....

The reason I decided to use it is because of the envirnoment of the car. If the cd track is recorded at a low volume on purpose, that is all fine and dandy for in the home or theatre or wherever, where the environment is much better and more suiting for the low track volume. In the car, often the road noise will make it to hard to hear the quiet tracks, so I normalize it to avoid having to adjust the volume when it plays, and then re-adjust after it is done for the next track. I find that most CD tracks have a peak around 98% as it is, so that is why I have it set there.

However, in addition to the above, I am only encoding these MP3's for use on the empeg, so obviously I am going to encode them the best to play on that and for the environment it is mainly used in (in my case, the Jeep)..
Just my two cents on the subject

--verteggio

In the car, often the road noise will make it to hard to hear the quiet tracks, so I normalize it to avoid having to adjust the volume when it plays, and then re-adjust after it is done for the next track.

You guys seem to think that normalizing somehow magically makes all your music play at the same volume. It doesn't. All it does is measure the single loudest peak in your song, then adds an equal amount of volume to the whole song so that the peak really does hit 100 percent (or 98 percent or whatever the setting is).

The problem is that most CDs you buy are already normalized, so setting the normalization flag in your ripper rarely does anything at all.

You could normalize every album in your collection and they would still sound like they were all played at different volumes. The reason is that every album is produced/mastered differently, and they all have different dynamics (relationships between loud and quiet parts). There are other threads on the BBS which discuss this subject, known as "dynamic compression".

In the meantime, I unconditionally normalize all my albums to 100 percent, just in case I happen to run into a CD that's not already normalized. This has actually happened to me a couple of times. Recently I got my hands on an old CD that had some songs peaking in the 70% range. In that (rare) case, normalization is very useful and helpful.

Doug "tanstaafl" Burnside has been struggling with normalization recently because his collection is a mixture of classical and rock/techno. The classical stuff is extremely dynamic, which also makes it seem to have a relatively quiet percieved volume compared to the rock and techno stuff. One of the ideas he was toying with was to take the rock recordings and normalize them DOWN to a low percentage, while leaving the classical pieces at 100 percent. Doug, what did your final solution end up being?

___________
Tony Fabris

I have sience found AltoMP3 Maker
Since you use Alto MP3, I had a question. On the options, CD-ROM screen is the option to Delete Silence Automatically with 2 input boxes (Leading Silent Frames and End Silent Frames). Are those boxes for how many frames to delete (which could result in chopped songs) or to include when encoding to MP3? I'd assume the latter but just want to be sure.

Thanks.

Squid2k1
---
18GB of Green Mk II Fury - Fast As A Shark

... take the rock recordings and normalize them DOWN to a low percentage, while leaving the classical pieces at 100 percent. Doug, what did your final solution end up being?

I ended up leaving them the way they were, all normalized to 98%. It turned out that I had to take a lot of normalization out of a rock song to get a really noticeable reduction of apparent volume compared to my classical songs, to the point where I was effectively compressing the dynamic range of the song by more than I was comfortable with.

I encoded Rush's "2112" at 100%, 80%, 60%, and 40% normalization and there was amazingly little difference in the apparent listening volume.

The normalization seems more effective at bringing quiet tracks up in volume than in taking loud tracks down.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

Has Anyone Looked at the WMA Format and what drawbacks or advantages it may have over MP3???

I try to keep all my music normalized. Most of the non-classical albums I have already seem to be normalized, although I think in some cases I have had to go back and re-rip with normalization.

For classical, normalization isn't enough because of the dynamic range, so I wrote a short program to compress out the extreme dynamics and make sure the entire track is as loud as possible. It works pretty well, although the background noise is much louder during the quiet passages, and some of the more dramatic parts of the music are washed out a bit because the extremes in volume are removed, causing some strange effects sometimes (although you still can easily hear the contrasts between "quiet" from "loud" parts). Purists would be horrified. But I definitely think it's worth it, because classical music is unlistenable in the car otherwise.. Half of it is inaudible and the other half is way too loud.

BTW I use musicmatch 4 to rip and encode at 128kbps.

I wrote a short program to compress out the extreme dynamics and make sure the entire track is as loud as possible.

Richard Lovejoy of this BBS wrote a custom kernel which does this in real-time on the Empeg. See the FAQ section of this BBS, under the heading "how do I put custom logos or kernels into the empeg?" for more information.

Hey, Doug, have you tried Rjlov's kernel yet?

___________
Tony Fabris

Hey, Doug, have you tried Rjlov's kernel yet?

No. I don't think rjlov's kernal will be the way to go for me, because the classical music I play relies so much on dynamic range for its effectiveness. I mean, just imagine what Ravel's "Bolero" would be like played through rjlov's volume-adjusting kernal. [shudder]

I am fortunate enough to have a pretty quiet automobile with a lot of pretty good speakers, and the difference between cabin noise at 30 MPH and, say, 70 MPH, is such that I only have to raise my player volume by two or three dB to compensate.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

A quick question on loading Rjlov's voladjust kernel with 1.01: is it just the same as 1.0? It was such a while ago I did it, but the studded snow tires go on soon and a moderately quiet car becomes a moderately loud car.

-Zeke

just say you weren't paying much attention...

A quick question on loading Rjlov's voladjust kernel with 1.01: is it just the same as 1.0?

Since it is a modified kernel, it is vital that you have the same version number as the current player software. If you only have his 1.0 kernel, you must download his 1.01 kernel if you wish to use it with the Empeg 1.01 player software.

There are no "on the surface" differences between 1.0 and 1.01, but he has added some "under the hood" hooks which allow you to link to a chooser program. I have been able to run this, and although it's useful, it's not quite ready for public consumption yet because the chooser doesn't display anything on the screen and it requires some fancy mucking about at the bash prompt to install it. Also, it requires the developer build in order to work. All the chooser program does is allow you to choose between "off", and "on" with two possible amounts of compression at boot time.

___________
Tony Fabris