ABR different filesize for each execution
Reply #35 – 2014-04-12 20:26:51
Isn't it much more common to use AAC for audio encoding with video? At a bitrate like 128 kbps you should get noticeably better sound quality than with LAME. That’s true in some cases but not really relevant here.what i've done is to take the output converted with lame, then reconverted in wav and compared it. maybe that's is a nonsense thing. What output? Did you do this once for each of two identical ABR files? And how, as saratoga just asked, are you comparing it? Have you paid attention to our warnings that file size alone is not a sufficient indicator of identity?but if I also use "output: vorbis" i get identical files, so this means that the problem is LAME related for sure Or, assuming you aren’t invalidating the comparison by not properly controlling it, maybe your frontend is just doing weird stuff in the background only when LAME is selected. Do me a favour: Take lame.exe, preferably the one from your frontend if available, use it on its own, encode the same file twice consecutively with identical settings, and tell us whether it produces actual differences in the output data (not just the file sizes) when used in isolation. For me, the lame.exe I have here does not:C:\Program Files (x86)\foobar2000>lame --abr 128 "C:\Program Files (x86)\foobar2 000\02-140412_1112.wav" c:\users\eprirjgsdgrjj\desktop\1.mp3 LAME 3.99.5 64bits (http://lame.sf.net) CPU features: SSE (ASM used), SSE2 (ASM used) Using polyphase lowpass filter, transition band: 20323 Hz - 20903 Hz Encoding C:\Program Files (x86)\foobar2000\02-140412_1112.wav to c:\users\eprirjgsdgrjj\desktop\1.mp3 Encoding as 48 kHz single-ch MPEG-1 Layer III (6x) average 128 kbps qval=3 Frame | CPU time/estim | REAL time/estim | play/CPU | ETA 289/289 (100%)| 0:00/ 0:00| 0:00/ 0:00| 46.240x| 0:00 32 [ 1] * 40 [ 0] 48 [ 0] 56 [ 0] 64 [ 0] 80 [ 0] 96 [ 0] 112 [129] ******************************************************** 128 [159] ********************************************************************* 160 [ 0] 192 [ 0] 224 [ 0] 256 [ 0] 320 [ 0] ------------------------------------------------------------------------------- kbps mono % long % 120.5 100.0 100.0 Writing LAME Tag...done ReplayGain: +64.8dB WARNING: ReplayGain exceeds the -51dB to +51dB range. Such a result is too high to be stored in the header. C:\Program Files (x86)\foobar2000>lame --abr 128 "C:\Program Files (x86)\foobar2 000\02-140412_1112.wav" c:\users\eprirjgsdgrjj\desktop\2.mp3 LAME 3.99.5 64bits (http://lame.sf.net) CPU features: SSE (ASM used), SSE2 (ASM used) Using polyphase lowpass filter, transition band: 20323 Hz - 20903 Hz Encoding C:\Program Files (x86)\foobar2000\02-140412_1112.wav to c:\users\eprirjgsdgrjj\desktop\2.mp3 Encoding as 48 kHz single-ch MPEG-1 Layer III (6x) average 128 kbps qval=3 Frame | CPU time/estim | REAL time/estim | play/CPU | ETA 289/289 (100%)| 0:00/ 0:00| 0:00/ 0:00| 63.055x| 0:00 32 [ 1] * 40 [ 0] 48 [ 0] 56 [ 0] 64 [ 0] 80 [ 0] 96 [ 0] 112 [129] ******************************************************** 128 [159] ********************************************************************* 160 [ 0] 192 [ 0] 224 [ 0] 256 [ 0] 320 [ 0] ------------------------------------------------------------------------------- kbps mono % long % 120.5 100.0 100.0 Writing LAME Tag...done ReplayGain: +64.8dB WARNING: ReplayGain exceeds the -51dB to +51dB range. Such a result is too high to be stored in the header. C:\Program Files (x86)\foobar2000>cd \users\eprirjgsdgrjj\desktop C:\Users\eprirjgsdgrjj\Desktop>fc /b 1.mp3 2.mp3 Comparing files 1.mp3 and 2.MP3 FC: no differences encountered (The input file is a nonsensical signal, but I assume that should not make any difference.)