Skip to main content

Topic: large mp3 encode time question (Read 8730 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?
  • Last Edit: 27 November, 2005, 04:41:17 PM by DCameronMauch

  • spoon
  • [*][*][*][*][*]
  • Administrator
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.

  • Alex B
  • [*][*][*][*][*]
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)

  • Alex B
  • [*][*][*][*][*]
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
  • Last Edit: 27 November, 2005, 06:52:15 PM by Alex B

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.

  • Alex B
  • [*][*][*][*][*]
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.

  • Never_Again
  • [*][*][*][*][*]
  • Members (Donating)
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].

  • indybrett
  • [*][*][*][*][*]
  • Members (Donating)
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.
  • Last Edit: 28 November, 2005, 11:59:22 PM by indybrett
flac>fb2k>kernel streaming>audiophile 2496>magni>dt990 pro

  • Alex B
  • [*][*][*][*][*]
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]

  • kritip
  • [*][*][*][*][*]
large mp3 encode time question
Reply #10
I believe beta 2 has a change related to that option. Worth checking out.

Kristian
  • Last Edit: 29 November, 2005, 11:11:21 AM by kritip

  • CRYON
  • [*]
  • Banned
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.
  • Last Edit: 30 November, 2005, 03:18:55 AM by CRYON

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.

  • Otto42
  • [*][*][*][*][*]
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.
  • Last Edit: 30 November, 2005, 01:38:33 PM by Otto42

  • Alex B
  • [*][*][*][*][*]
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.

  • kritip
  • [*][*][*][*][*]
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

  • rutra80
  • [*][*][*][*][*]
  • Members (Donating)
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].
  • Last Edit: 30 November, 2005, 02:41:21 PM by rutra80

  • Alex B
  • [*][*][*][*][*]
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.
  • Last Edit: 30 November, 2005, 03:25:46 PM by Alex B

  • Alex B
  • [*][*][*][*][*]
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.
  • Last Edit: 30 November, 2005, 03:38:38 PM by Alex B