VideoHelp Forum

Try DVDFab and copy Ultra HD Blu-rays and DVDs! Or rip iTunes movies and music! Download free trial !
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 45
Thread
  1. 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?
    Quote Quote  
  2. 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
    Quote Quote  
  3. 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.
    Last edited by TheLastOfThem; 13th Jul 2017 at 00:40.
    Quote Quote  
  4. 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.
    Quote Quote  
  5. Originally Posted by poisondeathray View Post
    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.
    Last edited by TheLastOfThem; 13th Jul 2017 at 01:29.
    Quote Quote  
  6. 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.
    Quote Quote  
  7. 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
    Quote Quote  
  8. It's also expressed as a percent change. Type -4.096 what do you get?

    .959
    Quote Quote  
  9. Originally Posted by poisondeathray View Post
    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.
    Quote Quote  
  10. 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).
    Quote Quote  
  11. 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
    Last edited by TheLastOfThem; 13th Jul 2017 at 02:59.
    Quote Quote  
  12. 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.
    Last edited by hello_hello; 13th Jul 2017 at 05:56.
    Quote Quote  
  13. Originally Posted by poisondeathray View Post
    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.
    Last edited by jagabo; 13th Jul 2017 at 08:01.
    Quote Quote  
  14. 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
    Quote Quote  
  15. Originally Posted by TheLastOfThem View Post
    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.
    Quote Quote  
  16. Originally Posted by poisondeathray View Post
    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?
    Quote Quote  
  17. Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    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
    Quote Quote  
  18. Originally Posted by poisondeathray View Post
    Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    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.

    Originally Posted by poisondeathray View Post
    You need to clear the boxes (backspace or delete)
    I tried that. No difference.

    Originally Posted by poisondeathray View Post
    And I used the multipler box, I didn't test the percent change.
    I have the same behavior with both.

    Originally Posted by poisondeathray View Post
    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.
    Quote Quote  
  19. Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    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
    Image Attached Thumbnails Click image for larger version

Name:	1.jpg
Views:	175
Size:	26.2 KB
ID:	42300  

    Click image for larger version

Name:	2.jpg
Views:	135
Size:	26.2 KB
ID:	42301  

    Quote Quote  
  20. Confirmed - I get the same problem with 2.1.3

    Originally Posted by jagabo View Post
    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 ?
    Quote Quote  
  21. Originally Posted by poisondeathray View Post
    Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    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
    Quote Quote  
  22. 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.
    Quote Quote  
  23. 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.

    Originally Posted by poisondeathray View Post
    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.
    Quote Quote  
  24. 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....?
    Quote Quote  
  25. Originally Posted by sneaker View Post
    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!
    Quote Quote  
  26. 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.
    Quote Quote  
  27. Originally Posted by poisondeathray View Post
    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...
    Quote Quote  
  28. Originally Posted by sneaker View Post
    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?
    Quote Quote  
  29. Originally Posted by TheLastOfThem View Post
    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.

    Originally Posted by TheLastOfThem View Post
    It is not doing it properly.
    How do you know this?

    Originally Posted by TheLastOfThem View Post
    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.
    Quote Quote  
  30. Originally Posted by ;2491236
    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.

    Originally Posted by ;2491236
    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...
    Quote Quote  



Similar Threads