Slashdot Mirror

This is completely false. For one thing, music CDs do not use the same data format as MP3s, so comparing bit rates is entirely misleading. For another, to be really technical, music CDs are recorded at 44100 samples per second, 16 bits per sample x 2 in stereo. That's approximately 1378kbits per second, not 120.

Finally, anything higher than 128kbits for MP3s is certainly not wasted bits. The fidelity of the MP3 increases dramatically as you raise the bit rate. I can always clearly tell the difference between a 128kbit MP3 and the original source when listening closely. 256k or 320k MP3s are difficult to impossible to tell from their sources, but they do come at a price in greater file size.

If you really want the best quality per byte, I highly recommend encoding with LAME with variable bit rate turned on. It's the best of both worlds: it only raises the bit rate when necessary to preserve the best audio quality, otherwise it uses a lower bit rate when it can without noticeable effects. I'm in the process of re-encoding my CD collection using this: the file sizes are typically only about 30% larger than 128k MP3s and the sound quality is far better, much closer to the original source.

Live webcasting is what I do. Check it out at the WRUW page. MP3 is definately the way to go. We have a 300 (clocked to 450) celeron and 128mb ram. It's on a dual board, so if we ever need more power, it'll be real simple. we've got a SB Ensoniq PCI soundcard that we feed our signal off or our airboard. We run Linux (duh :-),lame with some magic with named pipes and netcat and apache and we have as many streams as we want.

We also have an AudioActive hardware MP3 encoder, that the folks at Telos/Audioactive were kind enough to donate (They ROCK!). It encodes one signal (56kbps) and our server encodes another (24kbps).

I discovered that to the sound quality of 56k is comparable to a normal FM broadcast, so you really don't need a higher bitrate. The 24k stream is mono for modem users.

The biggest bottleneck is definately your bandwidth to the rest of the world. We are lucky enough at CWRU to have one of the worlds biggest ATM LANs. The 155MB/s of oncampus bandwidth is denfinately nice to have. We were on ethernet, and I was dreading possibility of crashing our Ethernet segment. Now with ATM, we can have unlimited on campus listeners (because more Case students have computers than radios :-) and our off campus bandwidth lets us have about 150 listeners from elsewhere. If you have more questions, please don't hesitate to email me. It should be pretty obvious as to what my email is :-)

Never mind, I found it at http://www.sulaco.org/mp3/.
Also, there are some excellent links from that page, including http://www.mp3tech.org/.
--

If you're a serious quality fiend, don't bother with 8hz, bladeenc or any of the other ISO derivitives. Typically, they only improve on the speed of the encoder, not the quality - and the standard ISO psycho acoustic model has a number of errors.

Go and download LAME. Lame Ain't an MP3 Encoder, it's a patch against the distribution 10 ISO example source which replaces the psycho acoustic model with GPSYCHO, adds variable bit rate support, joint stereo and a host of other goodies. I tested it out the other day, and it was consistantly encoding as fast as bladeenc and at a much better quality - less 'brittle' sounding in general, and without the high pitched sound artifacts that other encoders produce in about 20% of the things I've encoded (at 128 kbit, admitedly).

Bladeenc is not suggested due to the fact it uses ISO encoding not pyscho-aucstic(sp) which is much better.

No. Bladeenc uses the default psycho-acoustic model from the so called ISO dist10 source code. Unfortunately, this code has a large bug in it: the psy-model allocates bits for the left channel first, leaving the right channel with the minimum of four bits per subband in the worst case. This can be remedied by using huge bitrates with bladeenc, but that uses more space than encoding with LAME in a variable bitrate mode for the same quality.
Besides, songs encoded with a dist10 based encoder (8hz, bladeenc, others?) tend to lose some of the bass sounds (compared to the CD original).

Then there's the pre-echo detection bit, but you can read all about it here.

If you want a high bitrate of 160k you should probably use bladeenc. I just read the speed section of the homepage. On the other hand L3enc works well with lower bitrates (120k). Since I like small & good stuff I would naturally go for l3enc. But there is also LAME which is a patch to the ISO mp3 encoder source, allows VBR (variable bitrate encoding) and is 5 times faster than the original. You might want to try some batch frontends that provide CDDB acess to ease your work. Check out at freshmeat, I've seen lots of those.

If you want a high bitrate of 160k you should probably use bladeenc. I just read the speed section of the homepage. On the other hand L3enc work well for a lower bitrate (120k). Since I like small & good stuff I would naturally go for l3enc. But there is also LAME which is a patch to the ISO mp3 encoder source, allows VBR (variable bitrate encoding) and is 5 times faster than the original. You might want to try some batch frontends that provide CDDB acess to ease your work. Check out at freshmeat, I've seen lots of those.

Because of it's speed, I use Xing's command line encoder to encode. I use VBR HQ, and the resulting mp3's average around 200kbps for newer music. Some of my older music turns out around 112, and are still indistinguishable from the original. Not bad, considering that for difficult parts of the music it jumps up to 256 or 320kbps. For not-so-demanding portions, it will drop down to 96kbps. I also figure that drive space is so cheap that I shouldn't skimp on quality.

For ripping, I use cd-paranoia III on my linux box. That sucker can rip from dirty discs, even with a few scratches. It's slow, but yields a very stable wave file. I built a perl front end that looks the cd up at cddb.com. After it rips, it sends the wav file over to my PPro w/ WinNT, which encodes, tags and renames the file. Am I the only one that uses a cluster for creating mp3s? :)

I like fraunhofer's codec, but v3.1 doesn't run on WinNT (documented bug...) and it takes an eternity to encode files. Besides, they seem to be concentrating on 128kbps and below, mainly for streaming music over the internet. On top of that, there's no possibility of VBR.

My perception of BladeEnc is that it plainly sucks. Maybe that's because I've heard horrid-sounding samples of music encoded with this encoder. I just recently read that there are bad versions floating around. It seems that if Blade is compiled with code optimizations, the mp3 output turns out *different* from what it should.

I can't be sure, but there are two artifacts I hear most often in mp3s in a.b.sounds.mp3. The first is a distinct background, garbled digital wooshing sound, accentuated most when treble is turned up. The other artifact I hear I call "spoons". That's where you hear a really high-pitched "ping", like two spoons being whacked together, on cymbals and other high-toned instruments. I attribute these to Blade, probably unfairly, but there seems to be a lot of crappy mp3s out there... and someone doesn't know s/he's making them.

The most promising encoder I have seen is LAME (LAME Ain't an MP3 Encoder) (LAME). They just put in VBR support, and they have a much improved psycho-acoustic model over the ISO code. And it's all open source. Neat-oh!

MP3 encoders are just another religious debate in computer land. What really matters is which one sounds best to *YOU*. Do some experimenting, make sure you're using headphones. Try a few different encoders on the same wav file, and do A-B comparisons. Try different kinds of music (I found picking-guitar and audience applause are difficult for some encoders). You're correct: you only want to encode your collection once, so you want to make sure it's done right!

The last thing I want to mention is Joint Stereo. Personally, I like it, as it gives the left and right a little more room to store data, but I have noticed a *very* slight reduction in channel separation. The left and right aren't as separated as the original. It's extremely hard to notice, and in my opionion, very much worth the increase in quality.

-dodja

BUT... I've fallen in love with cdex and use it now instead. cdex rips (with very nice skip checking/reporting), cddb's, and encodes in one shot. Best of all, it uses LAME (Lame Ain't an MP3 Encoder), which is the closest thing we've got to a Legal, Free (Free Beer and Free Speech) MP3 encoder.

The LAME page links to a couple of Linux apps that do about the same in the Linux world: Grip (Gtk) and Krabber (KDE), but I've been happy enough with cdex that I haven't tried these yet.

BUT... I've fallen in love with cdex and use it now instead. cdex rips (with very nice skip checking/reporting), cddb's, and encodes in one shot. Best of all, it uses LAME (Lame Ain't an MP3 Encoder), which is the closest thing we've got to a Legal, Free (Free Beer and Free Speech) MP3 encoder.

The LAME page links to a couple of Linux apps that do about the same in the Linux world: Grip (Gtk) and Krabber (KDE), but I've been happy enough with cdex that I haven't tried these yet.

It totally depends on the bitrate and the encoder. A month back I encoded some stuff with BladeEnc and wasn't too impressed with 128kbit/s. At 256kbit/s I couldn't tell the difference from the original. Then I tried the LAME encoder (http://www.sulaco.org/mp3) and was pretty amazed how much better it sounded, even at low bitrates.

For both posters that were interested in LAME:
The official homepage is at
www.sulaco.org/mp3

Specifically, you can find source and binaries available
here. RPMS for
i586/glibc2.0, i586/glibc2.1 and alpha/glibc2.0 are available.

LAME compiles on Linux, Windows, Mac, and various
un*xes

LAME is is a patch agains the ISO MPEG1 demonstration sources. You have to download it and the dist10 ISO demonstration source.