Fast(er) transcoding from aac to mp3.

Simon Crisp simon at potatochip.co.uk
Fri Mar 18 20:06:23 EDT 2011


Looking back at my script I wrote back at Christmas when the iphone 
option stopped working and my programs started coming down in aac I seem 
to have a faster solution which works for me;

time( ffmpeg -i You_and_Yours_-_16_03_2011_b00zf33w_default.aac 
-map_meta_data 
You_and_Yours_-_16_03_2011_b00zf33w_default.mp3:You_and_Yours_-_16_03_2011_b00zf33w_default.aac 
You_and_Yours_-_16_03_2011_b00zf33w_default.mp3)

real    2m4.772s
user    2m2.440s
sys     0m1.580s

WRT to piping; I would guess that piping output of aac -> wav to wav -> 
mp3 is marginally faster than writing to a file and then reading from a 
file but surely it's faster to do everything in one go?

Sy

On 18/03/2011 16:22, Ian Stirling wrote:
> On 03/18/2011 03:50 PM, bat guano wrote:
>>
>>
>>
>> ----------------------------------------
>>
>>
>>> A test I did of
>>> time (ffmpeg -i You_and_Yours_-_16_03_2011_b00zf33w_default.aac -ab
>>> 128k test.wav; lame test.wav test.mp3)
>>>
>>> finished in 4:35 - this is on a core duo at 1.8GHz.
>>> So, 12* or so real-time.
>>
>> @ Ian
>> Surely you're performing two processes there?
>> First converting aac to wav...
>> then converting wav to mp3.
>>
>> Would it not be better to use a pipe?
>>
> Indeed it would, I couldn't be bothered working out how to get ffmpeg 
> to write, and lame to read from a pipe, as I already knew the syntax 
> to get it to do files.
> The time will change slightly, as the decoding and encoding canbe done
> on different cores, but not much, as the decoding is so enormously 
> faster.
>
> _______________________________________________
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer




More information about the get_iplayer mailing list