EAC3To Incorrect Slowdown? EAC3To Broke?

[TheLastOfThem]

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?

[poisondeathray]

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

[TheLastOfThem]

Can't just be the ratio?

It's a change of rate...also 99% of hydrogenaudio would say I'm right on this.

25-23.976

/ 25 = 4.096%

AKA

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.

[poisondeathray]

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.

[TheLastOfThem]

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.

Right. It is a ratio speed up but your math is still wrong. The ratio MUST account for the PERCENT CHANGE. it is a 4.096% difference. google it if you must.

try with audacity. the runtimes are NOT the same with EAC3To. Also it diesnt even come close to the. original percent you stated. At least its .002% closer to my calculation. I am doing it with M4A and NERO AAC. I appreciate your help a lot, but humbly must state your percent is off.

[poisondeathray]

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.

[poisondeathray]

audacity change speed is expressed as "speed multiplier" .

so 23.976/25 = 0.95904

our same 10 min sample in audacity becomes 10min 25 . 626 . or 625s.626

So basically the same thing as eac3to

[TheLastOfThem]

It's also expressed as a percent change. Type -4.096 what do you get?

.959

[TheLastOfThem]

audacity change speed is expressed as "speed multiplier" .

so 23.976/25 = 0.95904

our same 10 min sample in audacity becomes 10min 25 . 626 . or 625s.626

So basically the same thing as eac3to

Also with the 40 ms delay - the EAC3To audio is still SHORTER than the actual slowdown that audacity is doing originally.

[TheLastOfThem]

See this picture

https://snag.gy/jvMrYK.jpg

You and I are literally going back and forth on the same thing Lol.

Notice it's -4.096. Not -4.27094 like you originally said . Either way the runtime is not matching up with EAC3To (which comes out surprisingly shorter - by .002).

[TheLastOfThem]

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.

https://snag.gy/4xjgzy.jpg

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

[hello_hello]

MeGUI uses this to slow down:
SSRC(Round((AudioRate()*1001.0)/960.0)).AssumeSampleRate(AudioRate())
And this to speed up:
AssumeSampleRate(Round((AudioRate()*1001.0)/960.0)).SSRC(AudioRate())

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)
and
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

Whereas
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.

[jagabo]

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

25 fps is 4.270833333333333333333333333333 percent faster than 24000/1001.

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.

[poisondeathray]

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

[poisondeathray]

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.

https://snag.gy/4xjgzy.jpg

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

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.

[jagabo]

You can enter more than 3 decimal places in audacity.

I can't. When I try to type a forth digit past the decimal point it beeps and no digit appears. Maybe there's a setting somewhere?

[poisondeathray]

You can enter more than 3 decimal places in audacity.

I can't. When I try to type a forth digit past the decimal point it beeps and no digit appears. Maybe there's a setting somewhere?

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

[jagabo]

You can enter more than 3 decimal places in audacity.

I can't. When I try to type a forth digit past the decimal point it beeps and no digit appears. Maybe there's a setting somewhere?

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 ?

I was using 2.1.2. I updated earlier to 2.1.3 to see if there was a difference. There wasn't. It won't let me type more than three digits to the right of the decimal point.

You need to clear the boxes (backspace or delete)

I tried that. No difference.

And I used the multipler box, I didn't test the percent change.

I have the same behavior with both.

It affects the actual output (I processed them), not just the preview box time estimate

I discovered by accident that it accepts exponent format. For example, I can type in 959041e-6.

[poisondeathray]

You can enter more than 3 decimal places in audacity.

I can't. When I try to type a forth digit past the decimal point it beeps and no digit appears. Maybe there's a setting somewhere?

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 ?

I was using 2.1.2. I updated earlier to 2.1.3 to see if there was a difference. There wasn't. It won't let me type more than three digits to the right of the decimal point.

Weird. This is 2.1 portable version . I'll try 2.1.3 and look in the settings

[poisondeathray]

Confirmed - I get the same problem with 2.1.3

I discovered by accident that it accepts exponent format. For example, I can type in 959041e-6.

Nice - it works. But "typical" user wouldn't think of that notation would they ?

[TheLastOfThem]

You can enter more than 3 decimal places in audacity.

I can't. When I try to type a forth digit past the decimal point it beeps and no digit appears. Maybe there's a setting somewhere?

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 ?

I was using 2.1.2. I updated earlier to 2.1.3 to see if there was a difference. There wasn't. It won't let me type more than three digits to the right of the decimal point.

Weird. This is 2.1 portable version . I'll try 2.1.3 and look in the settings

Hey everyone!

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

[poisondeathray]

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.

[sneaker]

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.

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.

You say "padding" but I assume you are talking about encoder delay. We actually have both an encoder delay at the beginning and also padding at the end because of fixed frame sizes. For NeroAacEnc LC-AAC it is 2624 samples delay (at 48 kHz that's ~55ms) plus up to 1023 samples of padding at the end.

[TheLastOfThem]

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....?

[TheLastOfThem]

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.

So then what is right for making a perfect slowdown? Good point!

[sneaker]

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.

[TheLastOfThem]

jagabo posted a workaround if you ever need it for audacity, just use the other exponent notation
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).
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.

Welll everything I work on starts the way it starts...sometimes with a Fade in...didn't realize I had to do something to account for it....Didn't know exact encoder delays...so didn't know I would have to always SHAVE off blank audio..honestly that's a lot of work...

[TheLastOfThem]

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.

Using uncompressed audio isn't an option for the final result (too big). I want to stick to lossy formats. EAC3To I did do a WAV to WAV slowdown. It is not doing it properly. Does this mean I will always have to add a -50ms delay on the MKV containers?

[sneaker]

Using uncompressed audio isn't an option for the final result (too big).

I mean for testing only so you don't get confused by the AAC problems. Once you have it figured out what's wrong (or right) then go back to using AAC.

It is not doing it properly.

How do you know this?

Does this mean I will always have to add a -50ms delay on the MKV containers?

For wav to wav? No.

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.

[TheLastOfThem]

How do you know this?

I did the exact math and test of WAV to WAV madshi had me do. My result is not coming out to the proper # for a 10 minute sample. Sent him the documentation on it....and I hope he can help further...but for now it does seem like it's not working.

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.

So you mean - it will still write the delay even if I delete it off the ORIGINAL audio (assumign there's blank spaces).....and then MKVMErge will chop off more? Effectively doubling it..I see.....

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...