|
|
2017-07-12_23-57-45.png (109,050 bytes) |
|
|
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. Done. |
|
|
^ Runtime of the top is 10.25.602. Not the correct 10.25.626. Difference always varies from 24ms to 26 ms. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Ok.... 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. Done. For 10 minute sample at 25FPS runtime is 600000 |
|
|
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 total: 625,592 ms...... Crap |
|
|
Did you really repeat the test, using WAV input and WAV output? Or did you just do a writeup based on your older tests? |
|
|
NEWTEST.png (125,604 bytes) |
|
|
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. |
|
|
betterpic.png (185,017 bytes) |
|
|
Sorry I'm adding craptastic pictures. I'm adding a better one... |
|
|
best.png (177,370 bytes) |
|
|
On the right - is the NICE.WAV i converted to. |
|
|
On the left is the original nice wavpcm.wav file |
|
|
I am willing to teamviewer if necessary but yes...tried WAV to wav..I will try again.... |
|
|
newtestagain.png (147,001 bytes) |
|
|
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 |
|
|
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. |
|
|
Sure thing boss! |
|
|
https://www.amazon.com/clouddrive/share/4YcJaGELKcf44BwzmTMZ7HvXBCCmu8NcWUykOPr8Efu?ref_=cd_ph_share_link_copy |
|
|
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. |
|
|
Ah...wow 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? |
|
|
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. |
|
|
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? |
|
|
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 guessing....now I understand what you mean by resampling 2wice. |
|
|
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. |
|
|
Is it possible to humbly request to you - a build in which any 44.1 KHz file is interpreted as 48 KHz? Thank you.... |
|
|
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... |
|
|
An undocumented option would be MAGNIFICENT. Totally understand it isn't a 5 minute thing. Thank you for all your help brother :) |
- Anonymous
