Re: [AUDITORY] Converting audio file from WAV to MP3 changes file duration. Why? (Bob Masta )


Subject: Re: [AUDITORY] Converting audio file from WAV to MP3 changes file duration. Why?
From:    Bob Masta  <audio@xxxxxxxx>
Date:    Thu, 16 Nov 2017 08:26:27 -0500
List-Archive:<http://lists.mcgill.ca/scripts/wa.exe?LIST=AUDITORY>

Don't most browsers allow playing of .WAV files directly? That would solve your immediate problem, and also eliminate a much more insidious one that could come back to bite you down the road: Namely, that MP3 uses perceptual coding. It's essentially based on "tricking" the auditory system by omitting things it doesn't think most people will miss. It's a compromise between accuracy and file size. It was intended for "consumer" applications, not basic research. MP3 might be good enough for whatever you are doing, but in general it seems risky for auditory experiments that are trying to determine what people can perceive. Best regards, Bob Masta =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 15 Nov 2017 at 22:03, Neeraj Sharma wrote: > > Members, > > Thank you for the suggestions and the useful links. > In particular=A0http://lame.sourceforge.net/tech-FAQ.txt=A0 states the r= eason for increase in duration for WAV > to MP3. > Loosely stating, the increase is due to zero-padding at start and end. T= he zero-padding in the start > seems to be fixed (for the codec used) but that at end will depend on th= e 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 require= ment I have to use MP3s. > The issue is that: > 1. I do not have idea about the MP3 decoder used by the browser to decod= e the MP3s, and hence > the duration of audio file will potentially, have some unknown alteratio= ns. > 2. The time-stamps of the same events reported by listening to the stimu= li through browser, will > likely always have some (different) offset. > =A0 > Hence, estimating reaction time (as difference in the two timestamps) wi= ll always be > overestimated. > How much noise (in msec) in reaction time measurement for=A0sound stimul= i is insignificant? Any > suggestions on this will help in deciding the relevance for correcting t= he offsets.=A0 > > Best regards, > Neeks > > On Wed, Nov 15, 2017 at 5:15 AM, Julien Bloit <julien.bloit@xxxxxxxx> w= rote: > Hi,=A0 > > Zero-padding is applied for filtering purposes, see a > (rather old) explanation here:=A0 > http://lame.sourceforge.net/tech-FAQ.txt > > 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. > > Julien > > On Wed, Nov 15, 2017 at 8:57 AM, Windau, G.R.W. > (G=FCnter) <G.Windau@xxxxxxxx> 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=FCnter > > > On 15 Nov 2017, at 08:02, Neeraj Sharma > <neerajww@xxxxxxxx> wrote: > > Dear 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?=A0 I haven't been > able to figure this out. > > Similar issue has been reported by few others > also. > Example: > https://www.sweetwater.com/forums/showthread. > php?42631 > > Best regards, > Neeks > > > <duration_var_wav_mp3.png> > > - > ing. G=FCnter Windau | Technical Support Group=A0| =A0Dept. Biophysi= cs=A0|=A0 Donders Institute for Brain, Cognition and > Behaviour=A0|=A0Radboud =A0University Nijmegen=A0 |=A0 Heyendaalsewe= g 135, NL-6525AJ Nijmegen =A0| =A0room 00.817=A0| > =A0E:=A0G.Windau@xxxxxxxx=A0| T: +31 24 3613356=A0|=A0W:=A0http= ://www.mbfys.ru.nl/~gunter > > >


This message came from the mail archive
../postings/2017/
maintained by:
DAn Ellis <dpwe@ee.columbia.edu>
Electrical Engineering Dept., Columbia University