Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ABR different filesize for each execution (Read 10855 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ABR different filesize for each execution

Reply #25 –
all the configuration i can see in avidemux about audio encoder are these:

ABR different filesize for each execution

Reply #27 –
What makes you think the difference is in the MP3 audio portion of the video and not the DivX video encoding?

ABR different filesize for each execution

Reply #28 –
Quote from: JJZolx on
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

ABR different filesize for each execution

Reply #29 –
What's the audio codec used for "copy"?

ABR different filesize for each execution

Reply #31 –
Quote from: webpower on
all the configuration i can see in avidemux about audio encoder are these:


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.

ABR different filesize for each execution

Reply #32 –
Quote from: saratoga on
Quote from: webpower on
all the configuration i can see in avidemux about audio encoder are these:


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

ABR different filesize for each execution

Reply #33 –
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.

ABR different filesize for each execution

Reply #34 –
Quote from: webpower on
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. 

Quote from: webpower on
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?

ABR different filesize for each execution

Reply #35 –
Quote from: JJZolx on
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.

Quote from: webpower on
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?

Quote
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:
Code: [Select]
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.)

ABR different filesize for each execution

Reply #37 –
Quote from: JJZolx on
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.

ABR different filesize for each execution

Reply #38 –
Quote from: db1989 on
[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)

ABR different filesize for each execution

Reply #39 –
-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.
 

ABR different filesize for each execution

Reply #40 –
Quote from: db1989 on
-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.

ABR different filesize for each execution

Reply #41 –
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.

ABR different filesize for each execution

Reply #42 –
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.

ABR different filesize for each execution

Reply #43 –
Quote from: [JAZ] on

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.

ABR different filesize for each execution

Reply #44 –
that's ridiculous, i've encoded the file 15 times sequentially, and i got 15 different files, different are like this:

ABR different filesize for each execution

Reply #45 –
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.