hi all, i have an issue: i'm using "avidemux" which is a video encodind software that includes obviously an audio encoder (LAME): when I encode a video, i get a different size output file (few bytes), this not happens if I do use CBR encoding.
Somebody knows why of this?
thank you
If I don't miss any detail, LAME is a deterministic encoder, which means the same input (audio and settings and machine) necessarily produce the same output.
Since you say you have a slightly different output in something that is supposed to cause variability (ABR), I need to assume that the audio is really not the same. What might be happening in your back by avidemux is that the audio might get dither applied, so there might be small differences in the quiet parts. ( the loud parts wouldn't get affected at all, because the change would be under the threshold).
ok, thank you, but there is some way to know if dithering is the cause of this? if it is so, why do it affects only ABR and not CBR?
Dithering does not take place during encoding, only during decoding.
hi all, i have an issue: i'm using "avidemux" which is a video encodind software that includes obviously an audio encoder (LAME): when I encode a video, i get a different size output file (few bytes),
Different from what?
A few byes could be a different header or a tag (metadata).
(https://dl.dropboxusercontent.com/u/23394250/Screenshot%202014-04-10%2000.57.45.png)
here it is a "diff" between two encoded files.
If I understand that picture right, theres a little bit different at the front, and then the contents of one file are similar but shifted relative to the other. My guess is that the PCM audio isn't quite the same length between the two encodings.
Perhaps one has some more silence padded?
I don't know, the only thing I know is that for every encoding execution on the same OS, with the same software and the same parameter on the seame PC, produces a strightly different output file size
so? any other suggestion? I if you need more detailed information, ask me!
http://nopaste.info/2ef25e9f5d.html (http://nopaste.info/2ef25e9f5d.html)
here it is a log
ok, thank you, but there is some way to know if dithering is the cause of this?
I'd say, try avidemux but encode to WAV or a lossless codec and check the output files for differences
if it is so, why do it affects only ABR and not CBR?
Because if the length doesn't change (or only a little bit) CBR produces the same file size. However, with ABR, there is a part of the encoder that tries to decide which blocksize should be used, and that algorithm could be influenced by dither. It might choose a higher or lower bitrate for one or a few blocks.
ok, thank you, but there is some way to know if dithering is the cause of this?
I'd say, try avidemux but encode to WAV or a lossless codec and check the output files for differences
if it is so, why do it affects only ABR and not CBR?
Because if the length doesn't change (or only a little bit) CBR produces the same file size. However, with ABR, there is a part of the encoder that tries to decide which blocksize should be used, and that algorithm could be influenced by dither. It might choose a higher or lower bitrate for one or a few blocks.
yes, but i haven't undertood why it changes for every execution with all unchanged, no one thing i have changed.
ok, I've encoded to PCM, and in this case i get the same filesize for every encoding. so, the problem is ONLY with ABR LAME. I also tried using lame standalone with -V field, and in this case there is not the isseue. I'm very confused
yes, but i haven't undertood why it changes for every execution with all unchanged, no one thing i have changed.
You haven’t answered whether or not you are applying dither. If yes, as said above, dither is random and therefore will not be consistent (assuming a competent algorithm).
yes, but i haven't undertood why it changes for every execution with all unchanged, no one thing i have changed.
You haven’t answered whether or not you are applying dither. If yes, as said above, dither is random and therefore will not be consistent (assuming a competent algorithm).
ok, now the problem is how to know if dither is applied, can be understood from the log i've already pasted here?
Decode the output to wav, then do it again and see if the samples are identical or not.
Decode the output to wav, then do it again and see if the samples are identical or not.
"decode" ? maybe you would say "encode"
master input video source ---> output video source with mp3 abr ---> ...
please, continue the chain to explain better what I need to do, thank you
ok, i've encoded into wave file both the different output mp3 file, and will get 2 identical file.
so?, what does it mean?
What tool did you use to check that they were identical ?
And I did mean decode. Wav is uncompressed pcm.
What tool did you use to check that they were identical ?
And I did mean decode. Wav is uncompressed pcm.
no, sorry, they are not identical I just made a diff between two output file, they only have the same size again, but not identical.
Again, everything is pointing towards dither.
Even CBR would not produce identical audio under that condition – only size. Did you ever bit-compare the actual audio of the CBR ones?
ooh, i'm just stating that also with LAME CBR they get different output file for every execution, but they have only the same size, WTF
Probably some step is applying dither.
Edit: just because two files are the same size does not mean they are identical.
Again, everything is pointing towards dither.
Even CBR would not produce identical audio under that condition – only size. Did you ever bit-compare the actual audio of the CBR ones?
ooh, i'm just stating that also with LAME CBR they get different output file for every execution, but they have only the same size, WTF
I suspect there’s no reason to be mystified. Check what settings are actually being used throughout the processing chain. If dither is active, that explains absolutely everything you’ve observed.
if you have foobar2000, there is a component named foo_bitcompare (http://www.foobar2000.org/components/view/foo_bitcompare)
You would select the two wavs generated by two consecutive executions and under right-click mouse popup, utilities, Bit compare tracks.
You could also try with windiff, as you did with mp3. In that case, there would be dither if there are differences everywhere in the file (not necessarily all bytes, or consecutive bytes). If there are no, or just a few differences, then probably there isn't dither applied.
When I suggested dither as a possible cause, it was with the idea that the software might be working in floating point and then requiring a conversion when encoding that audio. Else, dither would not be needed.
It might also be the case that the software does stretching of the audio to accommodate for the video framerate, but then it should still produce the same output (because it would do the same changes).
I don't see anything special in the log. Just that it works at 48Khz and scales at 0.95, but probably both things are to be expected.
BTW: A wave file of the same length will always have the same size, (excluding cases where it could have different headers or tags).
all the configuration i can see in avidemux about audio encoder are these: (https://dl.dropboxusercontent.com/u/23394250/Screenshot%202014-04-12%2018.49.03.png)
if somebody could help me, these are a little piece with ABR:
first time encoding:
https://dl.dropboxusercontent.com/u/23394250/pr1.avi (https://dl.dropboxusercontent.com/u/23394250/pr1.avi)
second time encoding:
https://dl.dropboxusercontent.com/u/23394250/pr2.avi (https://dl.dropboxusercontent.com/u/23394250/pr2.avi)
What makes you think the difference is in the MP3 audio portion of the video and not the DivX video encoding?
What makes you think the difference is in the MP3 audio portion of the video and not the DivX video encoding?
avidemux presents various output mode for both video and audio. If i do use audio: "copy" i get identical output file, but if i use audio: "lame", i get these differences
What's the audio codec used for "copy"?
What's the audio codec used for "copy"?
i think the same as source, whitout re-encoding
all the configuration i can see in avidemux about audio encoder are these: (https://dl.dropboxusercontent.com/u/23394250/Screenshot%202014-04-12%2018.49.03.png)
You just showed us how decoded WAV files (which have not been through that encoder) have this problem too. Therefore, it is not the encoder, but rather the decoder that is the problem.
Check and see if there are settings for the decoder. If there aren't, either live with it or get different software.
all the configuration i can see in avidemux about audio encoder are these: (https://dl.dropboxusercontent.com/u/23394250/Screenshot%202014-04-12%2018.49.03.png)
You just showed us how decoded WAV files (which have not been through that encoder) have this problem too. Therefore, it is not the encoder, but rather the decoder that is the problem.
Check and see if there are settings for the decoder. If there aren't, either live with it or get different software.
no, wait, 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.
but if I also use "output: vorbis" i get identical files, so this means that the problem is LAME related for sure
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.
no, wait, 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.
Yes, that is a useless thing to do, and not what I was asking about.
but if I also use "output: vorbis" i get identical files, so this means that the problem is LAME related for sure
How are you determining that the files are identical?
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.)
but if I also use "output: vorbis" i get identical files, so this means that the problem is LAME related for sure
How are you determining that the files are identical?
windiff
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.
yeah, i've already considered it but something else told me that to get a good AAC I need a good encoder and FAAC and LAV which are the AAC encoders used in avidemux are not good.
plus AAC is less compatible than MP3, maybe AAC is more used in mkv.
[snipping pointless full quote—db1989]
1) I've taken the video master source ed encoded 2 times with the same setting output1.avi and output2.avi using lame abr as audio encoder, then I have extracted audio track from both the output ed encoded in a wave stream, then compared them with windiff.
2) yes, I know that it's not enough that both the file are with the same size to be identical, but in some cases I could be pretty sure that they are identical (wrongly) because it's highly improbable that the encoder produce the exact size, so I do it optimistically.
3) i already done encoding two times the file directly with lame.exe with "-V 128" field but in this case both the output are identical (with windiff)
-V invokes VBR, not ABR.
Anyway, I still think this is an issue of, and a question for, the developer(s) of your video-converting front-end, not LAME.
-V invokes VBR, not ABR.
Anyway, I still think this is an issue of, and a question for, the developer(s) of your video-converting front-end, not LAME.
tried with also --abr, and it's the same. I should try with libADM_ae_lame.dll which is the lame encoder that uses avidemux. Or maybe to know which parameter avidemux uses to encode the audio with lame.
Do you know how to use dithering? I can try lame.exe using it. to know if produces the same issue
Yes, but the avidemux developers are not easy to be reachable.
LAME cannot perform dithering. It wouldn’t make sense in that context: dither is used to mask quantisation distortion resulting from fixed-point encoding, but MP3 has no inherent bit depth.
Anyhow, dither is a standard feature of basically any audio editor, DAW, and so on. But I don’t think you need to worry about testing as it should indeed produce different output each time – because, again, it should be a completely* random* process. (*Insert huge mimed inverted commas here!)
By all signs, as far as I can tell, avidemux is doing something especially while sending audio to LAME, which is does not do for uncompressed or other lossy output.
If i haven't done anything wrong when decoding the files (I used VLC), there is a problem of audio offset in the videos you posted.
pr2 audio starts before than pr1 audio, and due to this, audio in pr1 is cut too soon.
After cutting and correcting offset, and verifying all things, both audio files are different. I doesn't seem a problem of dither.
If i haven't done anything wrong when decoding the files (I used VLC), there is a problem of audio offset in the videos you posted.
pr2 audio starts before than pr1 audio, and due to this, audio in pr1 is cut too soon.
After cutting and correcting offset, and verifying all things, both audio files are different. I doesn't seem a problem of dither.
for me they looks like identical in starting and finishing when I do play them.
that's ridiculous, i've encoded the file 15 times sequentially, and i got 15 different files, different are like this: (https://dl.dropboxusercontent.com/u/23394250/Screenshot%202014-04-12%2023.21.29.png)
And what did you expect? That it would only produce a few different versions and then cycle through them, sometimes being identical in some pairs? Of course not because, yet again, whatever is causing this, it’s random. And we’ve shown that it’s not LAME.