So I slowed down a file with EAC3To using -ChangeTo23.976 and -slowdown (same results).
I then took the original file and slowed it down -4.096% (Audacity) and it claims the runtime should be 23.06.675 NOT 23.06.649 as EAC3To is doing.
This is a difference of 36 ms....not to mention EAC3To keeps adding a 10 ms delay relative to the video, whereas the original 25 FPS file HAS NO DELAY on the audio.
What gives? People swore by EAC3to..I didn't realize it couldn't do simple math and realize slowdown is 4.096%! Not 4.094%!
Help...someone...is this normal along with the audio delay?
+ Reply to Thread
Results 1 to 30 of 45
25 / 23.976 = 1.0427094
ie. pal at 25fps is 4.27094% faster than 23.976. Where are you getting "4.096" from ?
23.976 is also an approximation . It's actually 24000/1001 exactly
Can't just be the ratio?
It's a change of rate...also 99% of hydrogenaudio would say I'm right on this.
/ 25 = 4.096%
25 Fps - 1.024 = 23.976
1.024 is 4.096% of 25.
There is no way it's 4.27094% faster.
The math also sadly makes no sense.
If you do 1.042/25 thats not 4.27094 % it's 4.170% aka 23.9575 fps not 23.976.
Despite that - EAC3To isn't agreeing with EITHER of our numbers.
Last edited by TheLastOfThem; 13th Jul 2017 at 00:40.
Yes , a simple speedup or slowdown (e.g. NTSC film DVD is spedup for PAL release) is just simple ratio speedup. Fact.
There are other variations done, +/- pitch shifting, but the simple speedup/slowdown method is the most common by far . You might have something else in your example
Yes, eac3to works , just tested . Maybe something broken on your end ? Maybe something else going on like a muxing offset, or compression delay ? Try with uncompressed pcm wav
60.0 s sample with slowdown applied becomes 62.563 s.
Last edited by TheLastOfThem; 13th Jul 2017 at 01:29.
Call it whatever you want. The math I wrote is right - This is how it's done in actual DVD production. I don't care about hydrogen audio. You're just doing the reverse what was done. Google it if you must. This is discussed about 348653904 times in the last few years.
So you're absolutely wrong . You can believe what you want.
Nero adds ~40ms compression delay . All compressed audio adds delay. Hydrogen audio people should know that . Try with uncompressed wav
10min or 600s sample with slowdown applied becomes 625s.621
We should have expected 600 * 25/(24000/1001) = 625s.625 , so 4ms off.
It's also expressed as a percent change. Type -4.096 what do you get?
I tried WAV just now. Same deal 23.06.649 - should be 23.06.675 (a difference of 26 ms) - and that's WITHOUT no encoder padding either if done right from the source on Audacity. I don't know what's possibly "broken" on my system. I tried on 4 PC's and this one is a fresh install of Windows 10...
Update: did FLAC, and WAV 10 minute sample on EAC3To and Audacity - both are approximately and exactly 26ms off, just like the above.
The EAC3To samples are 26 ms too short. Not to mention that's including an already added supposed "delay relative to video" of 10 ms....so confused
Last edited by TheLastOfThem; 13th Jul 2017 at 02:59.
MeGUI uses this to slow down:
And this to speed up:
It's pretty easy to create a script without speedup/slowdown and another with it, put Info() at the end of each and compare durations.
Accounting for a 36ms source delay would require DelayAudio(36.0/1000.0) before the conversion.
1001.0 / 960.0 = 25 / (24000/1001)
Maybe look at it this way:
(24000/1001) x 1.0427083333333333333333333333333 = 25
25 x 0.95904095904095904095904095904096 = (24000/1001)
1 - 0.95904 = 0.04096
but 100 / 95.904 = 1.042709
Or try doing the same thing with durations to be sure. A PAL frame has a 40ms duration so 1000 frames = 40000ms
For NTSC it's a 41.708333333333333333333333333333ms duration so 1000 frames = 41708.333333333333333333333333333ms
40000 * 25 / (24000 / 1001) = 41708.333333333333333333333333333
41708.333333333333333333333333333ms * (24000/1001) / 25 = 40000
40000 * 1.04096 = 41638.4
You're both not wrong, but isn't Audacity effectively saying you're reducing the speed to (100% - 4.096%), or to 95.9% or by 4.275% of 100%?
Edit: Or is it reduced by 4.275% of (100% - 4.096%), or by 4.275% of 95.9%? My brain hurts.....
(100 / 95.9 = 1.04275)
In which case I wouldn't put too much money on it's accuracy, given the real number is 1.0427083, which would make the real percentage 95.9041. I don't think Audacity offers enough decimal places for millisecond precision.
Last edited by hello_hello; 13th Jul 2017 at 05:56.
24000/1001 is 4.095904095904095904095904095904 percent slower than 25000.
There is no contradiction here. When one states percentages one must consider "percentage of WHAT". The two statements are comparing against different denominators.
Audacity's Change Speed filter is based on speed, not duration. To slow PAL to NTSC one should enter -4.096 percent. To speed NTSC to PAL one should enter 4.271 percent. Note that Audacity only lets you specify 3 digits to the right of the decimal point.
Last edited by jagabo; 13th Jul 2017 at 08:01.
You can enter more than 3 decimal places in audacity. It makes a difference. If you clear the boxes and enter 0.959041, I get 10 min 25 s . 625 , If you clear the boxes and enter 0.959, I get 10 min 25 s. 652
So audacity is perfect with enough decimal places. eac3to was only 4ms off in the 10min example here
Maybe problem with your example ? Maybe eac3to doing other processing things like gap removal ? Look at the log for details
So you are not starting with flush audio (it thinks there is a delay). It's probably trying to compensate
It's actually more complicated if you're using compressed audio (unless you plan to use that for your "final audio") . Even different AAC encoders use different padding. For Nero ~40ms , QAAC ~20ms (and you can adjust it) . QAAC is the highest rated AAC encoder at hydrogenaudio.
In video, a few +/- ms isn't a problem. The smallest increment , 1 frame, is 40ms for 25fps or ~41.71ms for 23.976 . Human can only distinguish about about 40-60 ms audio . And you can't "see" a partial frame.
I see there is a new 2.1.3 version, but this was on 2.1 . I don't think the version makes a difference, but maybe you're using a very old version ?
You need to clear the boxes (backspace or delete) , I think previous manipulations are saved - I noticed the numbers were off until I did that. And I used the multipler box, I didn't test the percent change.
It affects the actual output (I processed them), not just the preview box time estimate
Thank you all so much for your awesome help (jagabo, poison, hello).
I definitely cannot type in more than .959 on the multiplier - surprised you can Poison
Honestly I'm at a loss as to this whole situation...the 26 ms difference is making zero sense to me.
I am working with Madshi of EAC3To on this, but very confuzzled still. I have tried WAV64 like he suggests, yet him and I are also getting different numbers.
I have tried on every type of audio I can with a 10 minute sample - it just won't match up to what it should be neither 23.976 or even 23.976023976023976023976023976
jagabo posted a workaround if you ever need it for audacity, just use the other exponent notation
What INPUT are you using ? What is the background information ?
eac3to does other things like fix gaps, takes care of delays, removes bad audio "frames" . Audio padding (written into the stream) is different than a container stream offset (an A/V muxing delay).
So if you don't account for those when using audacity, you can go out of sync. Audacity will work fine if you have a clean stream and zero start time with no delays in terms of the video and container. If you started with an offset, but didn't account for that along the line, you will go out of sync assuming you started in sync. So even if you had the exact same duration, it doesn't help you if that puts you out of sync when you mux it with video
Everytime you encode with lossy encoder, some padding is added. It might only be a few ms for some (or up to 40ms for neroaac which is baaad), but it adds up. If it gets sent to youtube, another 20-40ms is added when it re-encodes.
Note that some algorithisms are not exact by design. This can be true for Audacity as well. Read "limitations" section of tempo manual for example.
From your posts it is not clear to me why you assume Audacity to be correct and eac3to to be incorrect. Could be other way around or both wrong.
NeroAacEnc LC-AAC it is 2624 samples delay (at 48 kHz that's ~55ms) plus up to 1023 samples of padding at the end.
Hi guys - regarding encoder delay - do you recommend always shaving off 55 ms of any source audio? But what if the audio has no gap? Then how do you account for that? If music starts RIGHT AWAY? This is depressing. I always thought the delay was merely 10ms at best. But seems no matter what it will add the delay.
I didn't know it added so much....?
Determine exact source duration. Then use a calculator with sufficient accuracy. For testing you might also want to try wav output from eac3to. Then you don't have problems with AAC artifacts.
Also, you have to be careful. NeroAacEnc writes info about the used delay into its output m4a file as metadata. Mkvmerge (and maybe other tools) can read and counteract this delay automatically. If you cut 55ms from your 48 kHz source Nero will not know this. It will still write the metadata. And mkvmerge will act on that.
Originally Posted by ;2491236
Originally Posted by ;2491236
EAC3To always gives me "delay relative to video 10ms" after a final mux with MKVMerge - is that .....accounted for??? or do I NEED to do -10 ms on the mkvtoolnix? It's .M4A from EAC3To...