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: 100 cycles of mp3->wav->mp3 (Read 4379 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

100 cycles of mp3->wav->mp3

Hey guys, I need a little help with something.

I am writing some software that stores a lot of audio.  I want to store the audio in mp3 to keep the file size reasonable.  The user can edit the audio so I need to convert it to wav for the editor.  I've had problems converting from mp3->wav->mp3, namely the volume (gain?) goes away after about just 50 cycles.  I found the LAME switch --scale 1 and now the volume stays constant but I get silence added to the front and back of the audio clip.  Here's my current LAME (3.96.1) command:

lame.exe --alt-preset cbr 320 --resample 44 --scale 1

Can someone suggest a commandline that will allow me to convert from mp3->wav->mp3 for at least 100 cycles with minimal reduction in audio quality?

Thanks!
- arlyn

ps: as you may have realized, I'm not an audio expert so thanks in advance for your patience

100 cycles of mp3->wav->mp3

Reply #1
I doubt that anything you do will leave the sound quality reasonable after 100 cycles of lossy -> wav -> lossy. Think seriously about using lossless encoding, or even leave them as wav.

100 cycles of mp3->wav->mp3

Reply #2
Well this is a good opportunity to ABX the first generation mp3 against the 100th, which is much more meaningful than this speculation that the sound quality won't be "reasonable".

As for the extra silence getting padded to the front and to the end, this can be avoided using the data stored in the lame header.

This link is pretty out-dated and I am havnig a difficult time searching for this, but hasn't the padding issue been addressed, or is this still on the to-do list?
http://lame.sourceforge.net/tech-FAQ.txt

EDIT:
The link to the official lame changelog is broken.  I was able to dig it out of Google's cache:
Quote
LAME 3.98 development
          o Fixed mp2 and mp3 decoding: For mp3 and mp2 decoding, this now yields the same output as foobar2000 but the error checking remains unchanged

100 cycles of mp3->wav->mp3

Reply #3
The notion that anyone would want to edit an audio file 100 times, or even 5 times, is interesting. Why might someone want to do that? What is the purpose of this particular storing of audio?

100 cycles of mp3->wav->mp3

Reply #4
The notion that anyone would want to edit an audio file 100 times, or even 5 times, is interesting. Why might someone want to do that? What is the purpose of this particular storing of audio?


In this app, people narrate a voiceover and then they edit the voiceover like trimming, cutting out words or re-recording portions.  You're right that 100 times is a boundary condition, but it's sort of the line I've drawn in the sand of what should be possible.

100 cycles of mp3->wav->mp3

Reply #5
I know this is rather callow comment, but why are you even messing around with a destructive editing framework if disk space is an issue? Why not use a nondestructive system, based on modifying scripts that mix/DSP the audio tracks together instead of saving each step to disk? It's not like you're at a loss for CPU time.

100 cycles of mp3->wav->mp3

Reply #6
I know this is rather callow comment, but why are you even messing around with a destructive editing framework if disk space is an issue? Why not use a nondestructive system, based on modifying scripts that mix/DSP the audio tracks together instead of saving each step to disk? It's not like you're at a loss for CPU time.

"Next version"

100 cycles of mp3->wav->mp3

Reply #7
As it's about trimming and cutting: why not use near lossless mp3DirectCut?
lame3995o -Q1.7 --lowpass 17