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: Odd behaviour for first file encoded (using EAC as frontend) (Read 2797 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Odd behaviour for first file encoded (using EAC as frontend)

Using EAC, I've ripped several albums to WAV for later processing (using LAME 3.90.2, or course!) using --alt-preset extreme.

I happened to be watching as the first WAV was encoded, and noticed that there were a few frames encoded at 32 kbps.  (the rest were 128 and up)

The rest of the .WAVs that encoded had no frames below 128.

This has occurred on every batch of .WAVs I've converted.  Is there something happening that I don't understand?  I thought that -b 128 was included in the --alt-preset exteme now (which appears to be the case on most of my encodes).  How are these few frames slipping through at 32?

It appears that it also happens if you encode manually.  Here's the screenshot. (sorry, I can't tell if this is formatted correctly for viewing!)

C:My DocumentsMy Music>c:progra~1encoderlame.exe --alt-preset extreme (01)e
a~1.wav
LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 19383 Hz - 19916 Hz
Encoding (01) Eagles - Get Over It.wav to (01) Eagles - Get Over It.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  8074/8077  (100%)|    1:49/    1:49|    1:49/    1:49|  1.9364x|    0:00
32 [  14] *
128 [ 150] %***
160 [ 434] %%%*********
192 [ 991] %%%%%%%%%%%%%%************
224 [1764] %%%%%%%%%%%%%%%%%%%%%%%***********************
256 [2574] %%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************************
320 [2150] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**********************
average: 250.3 kbps  LR: 3924 (48.58%)  MS: 4153 (51.42%)

Writing LAME Tag...done


Oh, kudos to Dibrom on such fine work and the clear explanations of why LAME is better!  If I hadn't accidentally run across this site, I'd still be using Xing!

Thanks!
Moe

Odd behaviour for first file encoded (using EAC as frontend)

Reply #1 –
32 kbit frames are used for digital silence in VBR, no matter what the minimum bitrate is set to. Since a song (or a CD) usually begins with some milliseconds of silence, that behavior of encoding some frames in 32 kbit is totally normal.

Odd behaviour for first file encoded (using EAC as frontend)

Reply #2 –
The 32 kbps frames are completely normal.
It is only done when a file has some digital silence (zeros),
usually at the beginning or the end....

If you no frames to drop below 128 kbps then add -F to your
commandline:

--alt-preset extreme -F

But if you ask me its not necessary...