Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Winamp 5 Ripping/Encoding (Read 4357 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Winamp 5 Ripping/Encoding

Hey all -

First, I'd like to say that you guys have one of the most informative forums around...  It's a great resource...  Anyway, I finally sat down and registered today...

... to ask you all a "n00bish" question.    Well, hope it's not too bad...

I am a fan of Winamp, and have followed the betas pretty closely.  But one feature I have my doubts about is the quality of the ripping/encoding.  I searched the forums here and there were a few referrences to Winamp 5, but nothing about it in depth.

Does Winamp use LAME?  The plugins folder has a "enc_lame" DLL and a "lame_enc.dll" DLL.  I suppose they are paying Fraunhofer for the method, but the encoder is still LAME?  Without the command line, is LAME - as implemented in Winamp 5 - pretty neutered?

How is the Sonic Ripping Engine?  I know it's not secure, but say you have an immaculate CD.  How would the quality be then?  If it's not good, would it be better to use the built-in ASPI engine, then?

Well, thanks in advance folks...  I appreciate the help...

Winamp 5 Ripping/Encoding

Reply #1 –
I cannot say anything about the Sonic engine or how good the LAME DLL performs, but I can tell you that the AAC encoder will cut all frequencies above 16 KHz even at high bitrates like 192 kbps.

Would be interesting if Roberto could test Winamp's AAC encoder in his 128 kbps listening test.

Edit: I was able to distinguish the Winamp AAC encoded song from the original 16/16 (used Noémi - Y.O.U.).

Winamp 5 Ripping/Encoding

Reply #2 –
Tests would be very much appreciated.  The whole ripping/burning aspect of Winamp is still very immature, and shouldn't be regarded as a replacement of programs like EAC or CDex.  I'm hoping we'll get alt-preset (now just plain presets in 3.94 beta) usage in an upcoming version.  Also, I'm interested if there will be any quality changes when/after mp4 aac coding is implemented.

-=Gonzotek=-
Winamp Forums Moderator
Please Keep Our Forum Clean!

Winamp 5 Ripping/Encoding

Reply #3 –
The version of lame_enc.dll is the short-lived v3.90 (v3.91 was released 8 days later). This is not the modified 3.90.x recommended versions on HA. This is one of the versions of lame_enc.dll (v3.90-3.92) that suffers from the CBR bug in which space for the LAME vbr/info tag is reserved at the beginning of the file but is never filled in, leaving you with 417 or 626 (or... etc) bytes of nulls at the beginning of your files. It would be great if the bundled lame_enc.dll would be a newer version, either v3.90.3 or 3.93.1

Winamp 5 Ripping/Encoding

Reply #4 –
The LAME options are in serious need of reworking. For something like Winamp (targeted at the casual encoder, I assume) the options should be much simpler to prevent users from getting confused over whether they should use "VBR mtrh" or "VBR-new", or if "multi-channel" is better than "stereo" - invariably most people will chose unwise settings. Something along the lines of a quality scale would be ideal:
  • Worst Quality (--preset 64)
  • Low Quality (--preset 112)
  • Good Quality (--preset medium)
  • High Quality (--preset standard)
  • Maximum Quality (--preset insane)
As it is, the default is CBR-128-stereo 
The drop-down quality selector gives some interesting/strange results, at least if you leave the other dropdowns in default values. The following is the results from ripping a 45-second CD track:
  • high = CBR128 (706560 bytes)
  • low = CBR128 (702464 bytes)
  • normal = CBR128 (700416 bytes)
  • r3mix = --r3mix -b128 (692224 bytes) - ABR=127kbps, all 128k frames except a few 32k's
  • very high = CBR128 (696320 bytes)
  • voice = CBR128 (696320 bytes)
All the files are CBR128 (except the r3mix one which is still CBR128 with a few 32kbps frames thrown in from digital silence)... but why are all the file sizes different (except "very high" == "voice" ?)

Winamp 5 Ripping/Encoding

Reply #5 –
getID3(): Forwarded your last two posts to the WA devs.

Cheers,
Gonzotek
Winamp Forums Moderator
Please Keep Our Forum Clean!
 

Winamp 5 Ripping/Encoding

Reply #6 –
Quote
I cannot say anything about the Sonic engine or how good the LAME DLL performs, but I can tell you that the AAC encoder will cut all frequencies above 16 KHz even at high bitrates like 192 kbps.

Would be interesting if Roberto could test Winamp's AAC encoder in his 128 kbps listening test.

Are you sure about it? I've tested the AAC engine with beta release of Winamp, on classical music and some sharp samples (for pre-echo), and I've found this encoder pretty good, close to iTunes AAC at 128 kbps. At higher bitrate, with samples like awe_32.wav or creaking.wav, this encoder suffered from a strange HF boost.

My tests were nevertheless very limited, because it's a real pain to encode short samples with this encoder (need to mount a virtual CD, and encoding speed is limited to x2 on free version). And I've didn't test anything else than classical at mid-bitrate or killer samples at 192 kbps.
But it seems that at 128 kbps, with classical, this encoder is really a good AAC challenger.
Wavpack Hybrid -c4hx6

Winamp 5 Ripping/Encoding

Reply #7 –
I have recorded a trance track (Noémi - Y.O.U.) with Winamp's AAC encoder at 192 kbps, decoded the file to WAV and loaded it in Adobe Audition. All frequencies above 16 KHz were cut. Also, the spectrum analyzer of Winamp did not show any peaks for the three bars at the right (which are for high frequencies).

Winamp 5 Ripping/Encoding

Reply #8 –
Shouldn't the Winamp AAC encoder be similar to the iTunes/QuickTime encoder in that they're based on the Dolby AAC codec (excluding any specific optimizations Apple/Nullsoft might have done).  That lowpass is quite annoying.