delaycut - ac3/eac3/dts/mpa/wav delay+cut tool: v1.4.3.7

Download the source. Make sure you have all the dev packages needed for compiling C++ and that you have qt4-qmake then run.

qmake -makefile delaycut.pro CONFIG+=Linux
make

So no new issues to report? Stereodude, did you happen to work up those values that were giving you inconsistent results between frames and milliseconds? Thanks.

[Stereodude]

Originally Posted by amtm

So no new issues to report? Stereodude, did you happen to work up those values that were giving you inconsistent results between frames and milliseconds? Thanks.

Sorry, not yet. I was out of town on vacation last week. I'll test the latest version and come up with sample numbers for you.

The short summary of what I saw seems to be that there is some combined rounding error when working in video frames vs ms because the starting delay in ms is rounded to a video frame number which then gets rounded to an AC3 frame number later. When dealing in ms there's only one round of rounding (no pun intended).

Okay, that's what I assumed it was. Yes, if the original input value is ms and you chose to use frames it converts to the next highest positive or negative frame to get a whole frame value since working in fractions of frames doesn't seem to make sense. But since the original code that calculates the target info only works in ms it gets then converted back to ms which means it's now at whatever matches that rounded frame number since it doesn't know that the original value in ms. I can add code to remember the original ms value so that you don't get the extra rounding.

[Selur]

Can delaycut handle mp3 files (or is mpa limited to mpeg-1 layer-1 and mpeg-1 layer-2 audio)?
because if I run:

delaycut -fixcrc fix -out "D:\Encoding Output\testNew.mp3" "D:\Encoding Output\test.mp3"

on this file, in the command line it seems like the program is finished, but the process is still running and with the gui delaycut is stuck at 99%.

as soon as one specifies a delay i.e. 0

delaycut -fixcrc fix -inputtype milliseconds -start 0 -out "D:\Encoding Output\testNew.mp3" "D:\Encoding Output\test.mp3"

delaycut terminates normally (but does not create an output file,..), so it only happens when using -fixcrc without a delay,.. (seems like a bug )

Cu Selur

Ps.: added bug to bugtracker (2012.01.04)

[pandv2]

I found this behaviour (bug fixing mp3 with silence) also (with the original delaycut). I doesn't reported it in this topic, because now I can't remember, nor find, the affected files, and no one new showed this bug.

The original wrong behavior was:

The process from delaycut never ends (nor return in my tests). A temporal file is created and grows. At the end, if the process is not stopped this file fill all the space in the hard disk.

Yeah, I tested it and I get the same behavior with both the new and original delaycut, too. I'm looking into it now.

BTW Selur if you are working in milliseconds you don't need to specify the inputtype since it defaults to millseconds if you don't specify the switch.

[Selur]

BTW Selur if you are working in milliseconds you don't need to specify the inputtype since it defaults to millseconds if you don't specify the switch.

I know.

[Stereodude]

Originally Posted by amtm

Okay, that's what I assumed it was. Yes, if the original input value is ms and you chose to use frames it converts to the next highest positive or negative frame to get a whole frame value since working in fractions of frames doesn't seem to make sense. But since the original code that calculates the target info only works in ms it gets then converted back to ms which means it's now at whatever matches that rounded frame number since it doesn't know that the original value in ms. I can add code to remember the original ms value so that you don't get the extra rounding.

So I have a file "DELAY 509ms.ac3" and am working in frames with a 2400/1001. I have "Cut file" and "Original length" checked. I have a Start of 62 and a End of 8325. It gives:

====== TARGET FILE INFO ==============
Start Frame 64
End Frame 10833
Num of Frames 10770
Duration 00:05:44.640
NotFixedDelay 5.0833
======================================

If I work in ms using excel and calculate the ms values myself I get a start of 2586ms and a end of 347222ms. It gives:

====== TARGET FILE INFO ==============
Start Frame 65
End Frame 10834
Num of Frames 10770
Duration 00:05:44.640
NotFixedDelay 3.0000
======================================

So, the number of AC3 frames and length are the same, but the scenario working in video frames has the start and end shifted by 1 AC3 frame.

[tebasuna51]

With Input Settings: Milliseconds
and load a DELAY 509ms.ac3
I get:

Delay -> Start (msec): 509
====== TARGET FILE INFO ==============
Start Frame -16 (512 ms)
...
NotFixedDelay -3.0000


With Input Settings: Frames, 23.976
and load a DELAY 509ms.ac3
I get:
Delay -> Start (frames): 13 (542.2 ms, incorrect, must be 12 -> 500.5 ms)

====== TARGET FILE INFO ==============
Start Frame -17 (544 ms, incorrect, must be -16 -> 512 ms)
NotFixedDelay -1.0000

If after check Cut file and
Cut File -> Start (frames): 62 (2585.9 ms)
Cut File -> End (frames): 8325 (8264 frames -> 344677.7 ms = 5:44.677)

====== TARGET FILE INFO ==============
Start Frame 64 (2048 ms, must be 65 -> 2080 ms, near to 2585.9 - 509 = 2076,9)
End Frame 10850 (must be 10835 = 10771 - 65 +1)
Num of Frames 10787 (must be 10771 = 344672 ms, near to 344677.7 ms)
Duration 00:05:45.184 (5:44.672)
NotFixedDelay 5.0807

If you check 'Cut File', check also Delay -> 'Original length' don't have sense for me (and maybe for others users).

Originally Posted by Stereodude

So I have a file "DELAY 509ms.ac3" and am working in frames with a 2400/1001. I have "Cut file" and "Original length" checked. I have a Start of 62 and a End of 8325. It gives:

====== TARGET FILE INFO ==============
Start Frame 64
End Frame 10833
Num of Frames 10770
Duration 00:05:44.640
NotFixedDelay 5.0833
======================================

If I work in ms using excel and calculate the ms values myself I get a start of 2586ms and a end of 347222ms. It gives:

====== TARGET FILE INFO ==============
Start Frame 65
End Frame 10834
Num of Frames 10770
Duration 00:05:44.640
NotFixedDelay 3.0000
======================================

So, the number of AC3 frames and length are the same, but the scenario working in video frames has the start and end shifted by 1 AC3 frame.

As I said, you see this shifted by 1 AC3 frame because the conversion logic as it is now always rounds the frame to the next highest positive or negative frame. So in your case it will round that 509ms which is ~12.2 frames up to 13 which then will be converted back to ms to calculate all that info which then gets changed to 542ms which pushes it to the next AC3 frame when the target info is calculated.

On the other hand, if fed 509ms what happens is that when calculating the start and end frame, the "gettargetinfo" method doesn't do any rounding but a simple truncation to a 64-bit integer when determining the start and end AC3 frame which is why you are get differing durations. So to fix this inconsistency we have two different solutions:

1) When converting to frames from ms truncate the frame value so that it matches how the "gettargetinfo" method determines start and end frame.

2) When converting to frames have start delay round down always and end delay round up always. And change this in both the UI code and in the "gettargetinfo" method.

I'm somewhat leaning towards option two as I think the naive truncation seems a bit odd to me. Now that I'm thinking about it more to me it now makes more sense that we would want original delay always to round down towards zero, which the current truncation behavior of "gettargetinfo" does, but to round the end delay to the next highest frame. I don't care either way but I'd love feedback on which choice everyone would prefer.

[phate89]

Originally Posted by amtm

So in your case it will round that 509ms which is ~12.2 frames up to 13

Why not round to the nearest frame? for example from 12.0 to 12.4 the result is 12 frames, from 12.5 to 12.9 is 13.. this could reduce the maximum variation from 31 ms to 16ms...
Correct me if i'm wrong..

Originally Posted by phate89

Why not round to the nearest frame? for example from 12.0 to 12.4 the result is 12 frames, from 12.5 to 12.9 is 13.. this could reduce the maximum variation from 31 ms to 16ms...
Correct me if i'm wrong..

That can be done too. My thinking for the second option to always round down the start delay you would never have an extra frame added to the rounding. Also for always rounding up the end delay you would make sure you'd never lose a frame due to the rounding. Though, I figure 1 frame isn't going to make a huge difference when it comes to maintaining video sync I would guess. As I said, I'm open to anyone's ideas. The issue is just making sure there is consistency between how rounding occurs when doing unit conversion in the UI and how the start/end frame rounding happens when the target info is calculated.

[Stereodude]

What about having delaycut work internally in ms even when you select working in video frames? IE: It converts video frames to ms and internally keeps the auto-populated start delay in ms despite showing it in video frames to the user.

That's how it already works. Like I said, even if you work in frames or seconds it gets converted to ms to be fed to calculate the target info. The problem is that I was using a different rounding scheme than the internal code was doing. It was just doing a simple truncation whereas I was doing an always round to the next frame scheme. This was why I was listing a couple of options to make the behavior similar. But it needs to be consistent between how the front end does the rounding when converting between units vs how the internal code does it's rounding.

[phate89]

Originally Posted by amtm

That can be done too. My thinking for the second option to always round down the start delay you would never have an extra frame added to the rounding. Also for always rounding up the end delay you would make sure you'd never lose a frame due to the rounding. Though, I figure 1 frame isn't going to make a huge difference when it comes to maintaining video sync I would guess. As I said, I'm open to anyone's ideas. The issue is just making sure there is consistency between how rounding occurs when doing unit conversion in the UI and how the start/end frame rounding happens when the target info is calculated.

iMHO the priority should be to make the editing more accurate possible... if you do only one edit 32 ms are nothing but if you do multiple editing they can in some case accumulate if you don't stay everytime to adjust the timings of the editing with not fixed delay...
Naturally when and if you will implement a intrack multiple editing you can consider this and automatically fix the following delays (add/remove the previous not fixed delay to the edit point and to the delay)... but even there i think that precision should be the priority... because if you edit in track sometime the silent space where you insert silence is small.. so more accurate it is less risk there are to insert the silence in not silenced points...
naturally this is what is best for my use of the program.. but i can't see the advantage of always round up...

Originally Posted by phate89

iMHO the priority should be to make the editing more accurate possible... if you do only one edit 32 ms are nothing but if you do multiple editing they can in some case accumulate if you don't stay everytime to adjust the timings of the editing with not fixed delay...
Naturally when and if you will implement a intrack multiple editing you can consider this and automatically fix the following delays (add/remove the previous not fixed delay to the edit point and to the delay)... but even there i think that precision should be the priority... because if you edit in track sometime the silent space where you insert silence is small.. so more accurate it is less risk there are to insert the silence in not silenced points...

That makes a lot of sense too. I'll try to get a version pushed out tonight or tomorrow night that fixes the rounding in both the UI and internal code to work in that manner.

Originally Posted by phate89

naturally this is what is best for my use of the program.. but i can't see the advantage of always round up...

Yeah, looking back it doesn't make a lot of sense.

I also haven't forgot about your issue, Selur, and thanks for submitting the issue to github. I've been having to reformat a lot of the internal code since it's something of a mess which has been making it a bit more difficult to track through.

[phate89]

can you add a checkbox to force the delay in silence? (for ac3,wav, mpa, for dts it's not easily possible)... actually if i add a delay and i make a cut in the middle of a file it simply start cutting before.. only if the previous frames aren't enough it creates the silence..
i think if someone wants to create a delay usually wants silence... it's a useful thing the ability to start to cut before (to loop content), but usually delay is silence and it's how it should work as default (leaving this method as option)

Unless I'm misunderstanding what you mean, delay is always inserted as silent audio frames. Or are you saying to only insert delay at a silent point in the original audio file? I'm not fully understanding what you are trying to ask for.

[phate89]

Originally Posted by amtm

Unless I'm misunderstanding what you mean, delay is always inserted as silent audio frames. Or are you saying to only insert delay at a silent point in the original audio file? I'm not fully understanding what you are trying to ask for.

Itry this params in the program
cut file:
start 10000 ms
end 40000 ms
delay (original length checked)
start msec 10000 ms

executed
i get exactly the first 30 seconds of the ac3 file... but what i want is 10 silence seconds and then audio from 10 to 40 seconds
maybe i'm doing something wrong

btw i found an ac3 audio track that make crash delaycut from command line and it don't do anything from gui... EAC3to handles it without problems..