IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
ABR different filesize for each execution, [moved from General Audio]
webpower
post Apr 12 2014, 17:50
Post #26





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



all the configuration i can see in avidemux about audio encoder are these:
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 18:10
Post #27





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



if somebody could help me, these are a little piece with ABR:

first time encoding:

https://dl.dropboxusercontent.com/u/23394250/pr1.avi

second time encoding:

https://dl.dropboxusercontent.com/u/23394250/pr2.avi
Go to the top of the page
+Quote Post
JJZolx
post Apr 12 2014, 18:19
Post #28





Group: Members
Posts: 395
Joined: 26-November 04
Member No.: 18345



What makes you think the difference is in the MP3 audio portion of the video and not the DivX video encoding?
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 18:39
Post #29





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (JJZolx @ Apr 12 2014, 19:19) *
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
Go to the top of the page
+Quote Post
JJZolx
post Apr 12 2014, 18:43
Post #30





Group: Members
Posts: 395
Joined: 26-November 04
Member No.: 18345



What's the audio codec used for "copy"?

This post has been edited by JJZolx: Apr 12 2014, 18:43
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 18:47
Post #31





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (JJZolx @ Apr 12 2014, 19:43) *
What's the audio codec used for "copy"?


i think the same as source, whitout re-encoding
Go to the top of the page
+Quote Post
saratoga
post Apr 12 2014, 19:52
Post #32





Group: Members
Posts: 4861
Joined: 2-September 02
Member No.: 3264



QUOTE (webpower @ Apr 12 2014, 12:50) *
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.
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 20:02
Post #33





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (saratoga @ Apr 12 2014, 20:52) *
QUOTE (webpower @ Apr 12 2014, 12:50) *
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
Go to the top of the page
+Quote Post
JJZolx
post Apr 12 2014, 20:05
Post #34





Group: Members
Posts: 395
Joined: 26-November 04
Member No.: 18345



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.
Go to the top of the page
+Quote Post
saratoga
post Apr 12 2014, 20:13
Post #35





Group: Members
Posts: 4861
Joined: 2-September 02
Member No.: 3264



QUOTE (webpower @ Apr 12 2014, 15:02) *
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 (webpower @ Apr 12 2014, 15:02) *
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?
Go to the top of the page
+Quote Post
db1989
post Apr 12 2014, 20:26
Post #36





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (JJZolx @ Apr 12 2014, 20:05) *
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 (webpower @ Apr 12 2014, 20:02) *
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
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.)

This post has been edited by db1989: Apr 12 2014, 20:28
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 20:27
Post #37





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (saratoga @ Apr 12 2014, 21:13) *
QUOTE (webpower @ Apr 12 2014, 15:02) *
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
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 20:30
Post #38





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (JJZolx @ Apr 12 2014, 21:05) *
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.
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 20:39
Post #39





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (db1989 @ Apr 12 2014, 21:26) *
[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)

This post has been edited by db1989: Apr 12 2014, 20:43
Go to the top of the page
+Quote Post
db1989
post Apr 12 2014, 20:43
Post #40





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



-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.
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 20:53
Post #41





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE (db1989 @ Apr 12 2014, 21:43) *
-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. smile.gif
Go to the top of the page
+Quote Post
db1989
post Apr 12 2014, 21:07
Post #42





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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.
Go to the top of the page
+Quote Post
[JAZ]
post Apr 12 2014, 21:10
Post #43





Group: Members
Posts: 1764
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



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.
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 22:04
Post #44





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



QUOTE ([JAZ] @ Apr 12 2014, 22:10) *

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.
Go to the top of the page
+Quote Post
webpower
post Apr 12 2014, 22:22
Post #45





Group: Members
Posts: 51
Joined: 7-December 13
Member No.: 112998



that's ridiculous, i've encoded the file 15 times sequentially, and i got 15 different files, different are like this:
Go to the top of the page
+Quote Post
db1989
post Apr 12 2014, 22:37
Post #46





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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.
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th July 2014 - 00:08