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: large mp3 encode time question (Read 10957 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

large mp3 encode time question

got a 13 hour audiobook in wav 16-bit 22.05kHz mono format
converted it to 40Mbs CBR mp3 in adobe audition in 5 minutes
tried lame 397b2 with "-b 40 -m m -h" and it estimated over 5 hours
even using the "-f" fast switch instead of "-h" estimated over 1 hour
what's the deal with that?

large mp3 encode time question

Reply #1
13 hour = 60x13 = 780 minutes

/ 5 minutes = x156 real time encoding.

Lame would be around x15 encoding, which is normal (depending upon computer), different encoders. BTW there is a Real Mp3 encoder that is much faster than Lame.

large mp3 encode time question

Reply #2
It can be adjusted:

Code: [Select]
Z:\Convert\Wave>lame 16-22mono15min.wav -b 40 -m m -h
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    1:01/    1:01|    1:01/    1:01|   14.756x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
ReplayGain: -14.9dB


Code: [Select]
Z:\Convert\Wave>lame 16-22mono15min.wav -b 40 -m m -f
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:42/    0:42|    0:42/    0:42|   21.101x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
ReplayGain: -14.9dB


Code: [Select]
Z:\Convert\Wave>lame 16-22mono15min.wav -b 40 -m m -f --noreplaygain
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:06/    0:06|    0:06/    0:06|   129.75x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1


With "-b 40 -m m -f --noreplaygain" my 15 min 16/22.05 test file was encoded in 6 seconds.

13 x 4 x 6 s = 312 s = 5 min 12 s

(XP/P4/2.8 Ghz, P4 hyperthreading enabled)

large mp3 encode time question

Reply #3
A small correction:

LAME doesn't show time values below 1 s. It truncates the decimal digits.

My test file was exactly 15 min 0.00 s. The speed was 129.75x.
The encoding time was: 15 x 60 / 129.75 = 6.94 s

13 x 4 x 6.94 s = 360.88 s = 6 min 0.88 s

large mp3 encode time question

Reply #4
I must have something seriously wrong going on.
Based on your calculations, my 13 hour file should encode
in just about 6 minutes.  But I still have an estimated
encode time of 1 hour 30 minutes..  My systems is an
XP/AMD64/4000+.  Seems like something is seriously wrong.

Hum.  Let is run for a long time and it failed with some
unknown error.  Twice.  Looks like the problem may be
with razorlame.  When I run lame from the command
prompt, it seems to be giving me the encode time I expected.

Guess it's time for another front end gui...

large mp3 encode time question

Reply #5
One more question while I am at it though:

The -q quality setting, think I am going to get any difference
I could notice between -h and -q0?  I would like to think I would
be getting something for 3x the encoding time.

large mp3 encode time question

Reply #6
Quote
The -q quality setting, think I am going to get any difference I could notice between -h and -q0?  I would like to think I would be getting something for 3x the encoding time.[a href="index.php?act=findpost&pid=345801"][{POST_SNAPBACK}][/a]

I don't have experience of encoding audio books. I suppose -h would be slightly better than -f (in case -f has audible problems). I have no idea what -q 0 might do. With usual music files and VBR settings like -V 5 and better I can't hear a difference in casual listening when -q 0 is added. At least -q 0 is not one of the commonly recommended options.

The speed drop from 130x to 21x when --noreplaygain is not used looks like a bug to me.

large mp3 encode time question

Reply #7
Quote
Guess it's time for another front end gui...
[{POST_SNAPBACK}][/a]
RazorLAME is obsolete and has been superceded by [a href="http://advasoft.beplaced.com/]AdvaLAME[/url].

large mp3 encode time question

Reply #8
Quote
got a 13 hour audiobook in wav 16-bit 22.05kHz mono format
converted it to 40Mbs CBR mp3 in adobe audition in 5 minutes
tried lame 397b2 with "-b 40 -m m -h" and it estimated over 5 hours
even using the "-f" fast switch instead of "-h" estimated over 1 hour
what's the deal with that?
[a href="index.php?act=findpost&pid=345723"][{POST_SNAPBACK}][/a]


5 hours? So...what's the problem?  Click the encode button, and go to bed.  When you wake up, it's done.
flac > schiit modi > schiit magni > hd650

large mp3 encode time question

Reply #9
Quote
5 hours? So...what's the problem?  Click the encode button, and go to bed.  When you wake up, it's done.[a href="index.php?act=findpost&pid=346157"][{POST_SNAPBACK}][/a]

It's not a problem if the time is normal. In this case the developers should look into this. I don't consider this speed drop without the "--noreplaygain" switch normal. (129.75x > 21.1x)

If it's normal an explanation would be nice. Perhaps the switch should be added to the HA recommendations for low bitrate & samplerate mono files. Even better would be if LAME could disable the replaygain check automatically when the used switch combination is going to result slowdowns like this.

Quote
Code: [Select]
Z:\Convert\Wave>lame 16-22mono15min.wav -b 40 -m m -f
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:42/    0:42|    0:42/    0:42|   21.101x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
ReplayGain: -14.9dB


Code: [Select]
Z:\Convert\Wave>lame 16-22mono15min.wav -b 40 -m m -f --noreplaygain
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:06/    0:06|    0:06/    0:06|   129.75x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
[a href="index.php?act=findpost&pid=345752"][{POST_SNAPBACK}][/a]

large mp3 encode time question

Reply #10
I believe beta 2 has a change related to that option. Worth checking out.

Kristian

large mp3 encode time question

Reply #11
Quote
Quote
Guess it's time for another front end gui...
[{POST_SNAPBACK}][/a]
RazorLAME is obsolete and has been superceded by [a href="http://advasoft.beplaced.com/]AdvaLAME[/url].
[a href="index.php?act=findpost&pid=346149"][{POST_SNAPBACK}][/a]


But this are all programs, that have small amount of options. For best tunning for encoding, u should use EncoderPro (http://www.scron.prv.pl/) , tool that is designed for HQ audio coding.

large mp3 encode time question

Reply #12
Quote
But this are all programs, that have small amount of options. For best tunning for encoding, u should use EncoderPro (http://www.scron.prv.pl/) , tool that is designed for HQ audio coding.
[a href="index.php?act=findpost&pid=346472"][{POST_SNAPBACK}][/a]


Hmm....  Anyone speak Polish?  Can't really tell just what this is.

large mp3 encode time question

Reply #13
Quote
It's not a problem if the time is normal. In this case the developers should look into this. I don't consider this speed drop without the "--noreplaygain" switch normal. (129.75x > 21.1x)
If it's normal an explanation would be nice.
[a href="index.php?act=findpost&pid=346281"][{POST_SNAPBACK}][/a]

Umm... Calculating ReplayGain values will *always* be slower than not calculating them. Regardless of any other switches.  I mean, it's a simple matter of doing the work vs. not doing the work.

By adding the --noreplaygain switch, you're telling it to not bother running the audio data through the ReplayGain algorithims to figure out the average volume. This won't affect the quality of the encode any, but it will mean that no RG information will be added to the LAME header.

large mp3 encode time question

Reply #14
Quote
Umm... Calculating ReplayGain values will *always* be slower than not calculating them. Regardless of any other switches.  I mean, it's a simple matter of doing the work vs. not doing the work.

By adding the --noreplaygain switch, you're telling it to not bother running the audio data through the ReplayGain algorithims to figure out the average volume. This won't affect the quality of the encode any, but it will mean that no RG information will be added to the LAME header.[a href="index.php?act=findpost&pid=346614"][{POST_SNAPBACK}][/a]

Usually the LAME replay gain analysis has very small effect to the encoding time.

In this case the effect was over 600%. Most likely it is because of the silent parts issue (LAME 397b2: "ReplayGain analysis should now be faster when encountering silent parts"). My artificial test file mimicked speech and included repeated silent passages.

large mp3 encode time question

Reply #15
@Alex B.
Did you also run the test with b2 then? Did it improve? The screen caps you posted say beta 1.

KRistian

large mp3 encode time question

Reply #16
Quote
Quote
But this are all programs, that have small amount of options. For best tunning for encoding, u should use EncoderPro (http://www.scron.prv.pl/) , tool that is designed for HQ audio coding.
[{POST_SNAPBACK}][/a]


Hmm....  Anyone speak Polish?  Can't really tell just what this is.
[a href="index.php?act=findpost&pid=346604"][{POST_SNAPBACK}][/a]

Translation:
"Converts WAV to MP3, MP4, AAC, and M4A. Has very advenced GUI and very fast algorithm giving high quality. Uses LAME, GOGO and SimpleEnc libraries for mp3 encoding and FAAC for mp4. Worth of recommendation as it offers advenced encoding options and simple & fast interface. Can save the configuration to a file or registry."
CRYON is the author, already [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=39273&hl=]discussed[/url].

large mp3 encode time question

Reply #17
Quote
Did you also run the test with b2 then? Did it improve? The screen caps you posted say beta 1.[a href="index.php?act=findpost&pid=346623"][{POST_SNAPBACK}][/a]

I have not downloaded b2 and tried it with anything yet. Unfortunately I deleted the 38 MB test file (I made it quickly in Wavelab just for checking this), but I'll try this with another file later.

Edit: I just found the file. I didn't delete it after all. I'll test it and post the results.

large mp3 encode time question

Reply #18
3.97b2 -b 40 -m m -f

Code: [Select]
Z:\test\noreplaygain>lame 16-22mono15min.wav -b 40 -m m -f
LAME 3.97 (beta 2, Nov 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:08/    0:08|    0:08/    0:08|   105.89x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
ReplayGain: -14.9dB


3.97b2 -b 40 -m m -f --noreplaygain

Code: [Select]
Z:\test\noreplaygain>lame 16-22mono15min.wav -b 40 -m m -f --noreplaygain
LAME 3.97 (beta 2, Nov 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:06/    0:06|    0:06/    0:06|   141.19x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1


3.97b1 -b 40 -m m -f

Code: [Select]
Z:\noreplaygain>lame 16-22mono15min.wav -b 40 -m m -f
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:39/    0:39|    0:39/    0:39|   22.529x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1
ReplayGain: -14.9dB


3.97b1 -b 40 -m m -f --noreplaygain

Code: [Select]
Z:\noreplaygain>lame 16-22mono15min.wav -b 40 -m m -f --noreplaygain
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 10403 Hz - 10669 Hz
Encoding 16-22mono15min.wav to 16-22mono15min.wav.mp3
Encoding as 22.05 kHz  40 kbps single-ch MPEG-2 Layer III (8.8x) qval=7
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
34457/34457 (100%)|    0:06/    0:06|    0:06/    0:06|   137.50x|    0:00
-------------------------------------------------------------------------------
  kbps       mono %     long switch short %
  40.0      100.0        66.3  16.7  17.1


LAME 3.97b2 is much better. Also the "--noreplaygain" option is slightly faster (I tried this three times to make sure).

The test PC has a different faster setup now. That's why I tested LAME 3.97b1 again.