madshi bug tracker - eac3to
View Issue Details
0000487eac3tobugpublic2017-07-13 09:082017-07-14 20:38
0000487: Slowdown / ChangeTo23.976 BROKEN on EAC3TO
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. (I'm unclear if the delay is due to AAC encoder Nero AAC but maybe!)

Slowdown is 4.096%! Not 4.094%! It's off by 2%.
Find 10.002s (in my case) minute sample of any audio file.

In audacity slow it down using .959 multiplier (Speed Change) or -4.096%.

It will state - 10min 25 . 628 as proper slowed down runtime of 23.976 FPS.

Do the same with EAC3To on this exact sample (any format - FLAC, WAV, M4A to M4A - FLAC TO FLAC, WAV TO WAV - doesn't matter).

Import into Audacity.

Check runtime....Audacity reports it is 10.25.602 (a whole 26 ms shorter!)

Nowhere close.
This is super disappointing. I trusted EAC3To in being accurate, but I have been incredibly let down and feel deceived.
No tags attached.
png 2017-07-12_23-57-45.png (109,050) 2017-07-13 09:11

png NEWTEST.png (125,604) 2017-07-13 22:23

png betterpic.png (185,017) 2017-07-13 22:25

png best.png (177,370) 2017-07-13 22:26

png newtestagain.png (147,001) 2017-07-13 22:29
Issue History
2017-07-13 09:08TheLastOfUsNew Issue
2017-07-13 09:11TheLastOfUsFile Added: 2017-07-12_23-57-45.png
2017-07-13 09:25TheLastOfUsNote Added: 0001713
2017-07-13 09:26TheLastOfUsNote Added: 0001714
2017-07-13 11:15madshiNote Added: 0001715
2017-07-13 21:57TheLastOfUsNote Added: 0001716
2017-07-13 22:06madshiNote Added: 0001717
2017-07-13 22:11TheLastOfUsNote Added: 0001718
2017-07-13 22:15TheLastOfUsNote Added: 0001719
2017-07-13 22:17TheLastOfUsNote Added: 0001720
2017-07-13 22:18TheLastOfUsNote Added: 0001721
2017-07-13 22:19madshiNote Added: 0001722
2017-07-13 22:22TheLastOfUsNote Deleted: 0001721
2017-07-13 22:22TheLastOfUsNote Deleted: 0001720
2017-07-13 22:23TheLastOfUsFile Added: NEWTEST.png
2017-07-13 22:23TheLastOfUsNote Added: 0001723
2017-07-13 22:23TheLastOfUsNote Edited: 0001723bug_revision_view_page.php?bugnote_id=1723#r424
2017-07-13 22:25TheLastOfUsFile Added: betterpic.png
2017-07-13 22:25TheLastOfUsNote Added: 0001724
2017-07-13 22:26TheLastOfUsFile Added: best.png
2017-07-13 22:27TheLastOfUsNote Added: 0001725
2017-07-13 22:27TheLastOfUsNote Added: 0001726
2017-07-13 22:28TheLastOfUsNote Added: 0001727
2017-07-13 22:29TheLastOfUsFile Added: newtestagain.png
2017-07-13 22:31TheLastOfUsNote Added: 0001728
2017-07-13 22:49madshiNote Added: 0001729
2017-07-13 23:00TheLastOfUsNote Added: 0001730
2017-07-13 23:08TheLastOfUsNote Added: 0001731
2017-07-13 23:40madshiNote Added: 0001732
2017-07-13 23:46TheLastOfUsNote Added: 0001733
2017-07-13 23:50madshiNote Added: 0001734
2017-07-14 00:07TheLastOfUsNote Added: 0001735
2017-07-14 00:10TheLastOfUsNote Edited: 0001735bug_revision_view_page.php?bugnote_id=1735#r426
2017-07-14 00:11TheLastOfUsNote Added: 0001736
2017-07-14 00:13TheLastOfUsNote Added: 0001737
2017-07-14 00:26TheLastOfUsNote Deleted: 0001736
2017-07-14 00:27TheLastOfUsNote Edited: 0001735bug_revision_view_page.php?bugnote_id=1735#r427
2017-07-14 00:29TheLastOfUsNote Added: 0001738
2017-07-14 00:30TheLastOfUsNote Added: 0001739
2017-07-14 00:32TheLastOfUsNote Deleted: 0001738
2017-07-14 00:32TheLastOfUsNote Deleted: 0001739
2017-07-14 00:33TheLastOfUsNote Deleted: 0001737
2017-07-14 00:41TheLastOfUsNote Added: 0001740
2017-07-14 01:25madshiNote Added: 0001741
2017-07-14 04:07TheLastOfUsNote Added: 0001742
2017-07-14 09:47madshiNote Added: 0001743
2017-07-14 09:47madshiAssigned To => madshi
2017-07-14 09:47madshiStatusnew => assigned
2017-07-14 20:38TheLastOfUsNote Added: 0001744

2017-07-13 09:25   
eac3to v3.31
command line: eac3to "WAVPCM.wav" "wow.m4a" -slowdown
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.50> with NeroAacEnc...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 32 bits.
eac3to processing took 19 seconds.
2017-07-13 09:26   
^ Runtime of the top is 10.25.602. Not the correct 10.25.626.

Difference always varies from 24ms to 26 ms.
2017-07-13 11:15   
I've just done the following test with the Robin Hood (Disney) audio track:

1) "eac3to English.flac Stereo.wav -downStereo". Audacity reports final audio file to be 1:23:01.984.

2) "eac3to Stereo.wav Slowdown.wav -slowdown". Audacity reports final audio file to be 1:26:34.756.

Now let's do the math:

1:23:01.984 = ((1 * 60 + 23) * 60 + 01) * 1000 + 984 = 4981984 milliseconds
4981984 * 25 / (24.000 / 1.001) = 5194756 milliseconds
5194756 / 1000 / 60 = 86 minutes
5194756 - 86 * 60 * 1000 = 34756 milliseconds

So final length should be 1:26:34.756 - which is exactly what eac3to produced! So we have a *perfect* match. At least in this specific test I just made.

Two things you might not have been aware of:

A) 23.976 is really 24.000 / 1.001 = 23.976023976023976023976023976...

B) When decoding from or encoding to some compressed formats like e.g. AC3, DTS, AAC etc, audio gets either shortened or lengthened to match the compressed format's frame size. So for a really exact test both your source and target format should ideally be WAV(64), because WAV is one of the very few formats which doesn't partition the audio data into frames of a specific size.
2017-07-13 21:57   
Dear Madshi

Thanks for your response.

I did try WAV of a 10 minute sample as you can see in my 1st note. That 10 minute sample ends up becoming 10.25.602 .WAV and not 10.25.626 like a simple -4.096 on Audacity is doing.

Did you try on Audacity? I mean I am adding 23.976 (i may not be putting in 023976023976023976023976) but then how come the audio is shorter (especially wav)?

Please try just 10 minute sample of any audio.
2017-07-13 22:06   
I'm not interested in whether Audacity resamples to a different duration than eac3to. I'm only interested in whether eac3to does things correctly. And as you can see in my previous comment, in my test it produced perfect results.

Your log includes AAC, which can screw everything up.

You're welcome to repeat my test with any file of any (reasonable) runtime. But if you do, please don't compare with what other software is doing (when slowing down). Instead just do the math manually to double check if eac3to is doing things correctly or not. That's the only thing that counts! And if you do this test, please use WAV for both input and output.
2017-07-13 22:11   

I honestly can't say I know the math entirely.

eac3to v3.31
command line: eac3to wavpcm.wav nice.wav -slowdown
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "nice.wav"...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 9 seconds.

For 10 minute sample at 25FPS runtime is 600000
2017-07-13 22:15   
600000 * 25 / (24/1.001) aka 15000000/23.976023976 = 625625 ms

Audacity says EAC3To audio is 10 minutes 25 seconds 592 milliseconds

10 mins = 600000 ms
25 seconds = 25000ms
592 ms = 592ms


625,592 ms......

2017-07-13 22:19   
Did you really repeat the test, using WAV input and WAV output? Or did you just do a writeup based on your older tests?
2017-07-13 22:23   
I did a new test....attached for your reference. Apologies but it still isn't adding up right...wouldn't waste your time with lies! I'm trying hard to figure this out on my end.

2017-07-13 22:25   
Sorry I'm adding craptastic pictures. I'm adding a better one...
2017-07-13 22:27   
On the right - is the NICE.WAV i converted to.
2017-07-13 22:27   
On the left is the original nice wavpcm.wav file
2017-07-13 22:28   
I am willing to teamviewer if necessary but yes...tried WAV to wav..I will try again....
2017-07-13 22:31   
Newtestagain.png added. Wavpcm.wav to nice.wav

Final result is 10.25.592 as reported by audacity. Not 625625 ms as I calculated with your exact ratio. If I try a bigger file - up to 30 minutes, same discrepancy in numbers
2017-07-13 22:49   
Strange. Why does it work on my PC? My file is not float32, though, but I don't think that's likely to make a difference. Can you upload the "Wavpcm.wav" somewhere? Then I'll try to reproduce the problem here with the exact same file you've been testing with.
2017-07-13 23:00   
Sure thing boss!
2017-07-13 23:08 [^]
2017-07-13 23:40   
Interesting. It seems to be the sampling rate. When I convert the audio to 48khz, slowing down produces perfect results. But at 44.1khz it's not perfect.

After checking my source code it seems that the libSsrc library I'm using for resampling has "integer" parameters for source and target sampling rate, not "floating point". Which means the sampling rates are rounded down, no decimals supported. I'm not sure if there's much I can do about this.
2017-07-13 23:46 that would explain a lot. Yes all my audios I work on are 44.1 - and yes I don't think there's anything you could do about it....thank you for looking into this.

Is there a way for the audio to be converted to 48 Khz right from within EAC3To or would it require me to use Audacity > save to wav > then process?
2017-07-13 23:50   
Why are your audio files 44.1khz? I mean usually slowdown is needed for *movie* tracks, and both DVDs and Blu-Rays (and UHD Blu-Rays and HD DVDs) are all 48khz, IIRC. So I don't understand where you would get 44.1khz movie tracks from? Except maybe from Laserdisc or something?

For non-movie tracks of course it isn't nice if slowdown isn't perfect, but it's probably not a too dramatic problem, either, because there's no matching video track that lipsync needs to match with. But if there's no video track, I don't think slowdown would ever be useful, anyway?

eac3to can directly resample, e.g. "eac3to source.wav target.wav -resampleTo48000", but then you resample twice: From 44.1khz to 48khz, and then afterwards the slowdown, which isn't ideal.
2017-07-14 00:07   
(edited on: 2017-07-14 00:27)
It's a laserdisc of winnie the pooh from Europe. Which is why it's probably 44.1 KHz....

wouldn't resample be just once? eac3to source.wav (resampled) -slowdown ?

Oh you mean the audio gets manipulated twice? I thought it was close to perfect if your sources are lossless?

2017-07-14 00:41   
I did Resampleto48000 and it changed the file length from 22.09.876 to 22.09.853 difference of 24 ms.

Basically if I work with any 44.1 KHz file - no go in terms of libSsrc I am I understand what you mean by resampling 2wice.
2017-07-14 01:25   
Yeah. Don't know how to solve it. I mean I could lie to libSsrc about the sampling rate and pretend it were 48khz instead of 44.1khz, but I don't know enough about the technical aspects of resampling. It might harm audio quality if I lie, I don't know for sure.
2017-07-14 04:07   
Is it possible to humbly request to you - a build in which any 44.1 KHz file is interpreted as 48 KHz?

Thank you....
2017-07-14 09:47   
I don't really want to do that by default, because I don't know if it might not harm audio quality. I could add it as an (undocumented) option. It's not a matter of 5 minutes to add this, though, so it will have to wait...
2017-07-14 20:38   
An undocumented option would be MAGNIFICENT. Totally understand it isn't a 5 minute thing. Thank you for all your help brother :)