Members,Thank you for the suggestions and the useful links.In particular http://lame.
sourceforge.net/tech-FAQ.txt states the reason for increase in duration for WAV to MP3.Loosely stating, the increase is due to zero-padding at start and end. The zero-padding in the start seems to be fixed (for the codec used) but that at end will depend on the input file duration (or number of samples).Why this is bothering me is:I have a sound stimuli created in WAV. I have created time stamps to map to certain significant "waveform events" in the signal.I will be playing back these stimuli in HTML, and due to certain requirement I have to use MP3s. The issue is that:1. I do not have idea about the MP3 decoder used by the browser to decode the MP3s, and hence the duration of audio file will potentially, have some unknown alterations.2. The time-stamps of the same events reported by listening to the stimuli through browser, will likely always have some (different) offset.Hence, estimating reaction time (as difference in the two timestamps) will always be overestimated.How much noise (in msec) in reaction time measurement for sound stimuli is insignificant? Any suggestions on this will help in deciding the relevance for correcting the offsets.Best regards,NeeksOn Wed, Nov 15, 2017 at 5:15 AM, Julien Bloit <julien.bloit@xxxxxxxxx> wrote:Hi,Zero-padding is applied for filtering purposes, see a (rather old) explanation here:A command line tool like "afinfo" will be able to tell you how many valid audio frames are in the mp3, and which are the priming and reamainder frames.JulienOn Wed, Nov 15, 2017 at 8:57 AM, Windau, G.R.W. (Günter) <G.Windau@xxxxxxxxxxxxx> wrote:Dear Neeks,Your wav audio files can have an arbitrary lenght, depending on the duration of the audio sample. The mp3 audio file however, is a sequence of frames with a certain length in bytes, and thus also in duration. After going from wav to mp3 and back, you will see that the the duration of your audio sample has changed. I guess there will be some zero padding or small conversion artifacts before and after the 'real' audio.This may have been designed this way to prevent the introduction of audible clicks at the beginning and at the end when playing an mp3 file.If you need the duration of your audio files to be maintained, mp3 may not be what you want.Best wishes,GünterDear Members,An audio file in WAV can be converted to MP3 using following two utilities in unix terminal (both work, and there may be many more also):$ ffmpeg -i <input.wav> -codec:a libmp3lame -b:a 320k <output.mp3> </dev/null$ lame -q0 -b128 <input.wav> <output.wav>But the issue is that the duration of <output.mp3> is more than duration of <input.wav>. This is true with other utilities which I have tried, like sox. Can anyone give insight on:a. why the duration is increasing? In the attached image below, the duration variation is plotted for 410 sound files. The increase in duration appears to be WAV file dependent (although it is within 140ms in this case)b. is there option in the above utilities which can reduce this difference in duration? I haven't been able to figure this out.Similar issue has been reported by few others also.Best regards,Neeks<duration_var_wav_mp3.png>