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

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.

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:

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.

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"

As it's about trimming and cutting: why not use near lossless mp3DirectCut?