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

[amtm]

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

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

[Stereodude]

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

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

[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 (http://www.multiupload.com/EP8QSLGCJC) 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.

[amtm]

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]

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

[amtm]

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]

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

[amtm]

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.

[amtm]

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]

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

[amtm]

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.

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)

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

[phate89]

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

[amtm]

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

Don't click "original length" in that case then. When you check that option it sets the end delay to the equivalent of your start delay so that length isn't changed. In that example you're cutting out a 30 second segment and it is maintaining that 30 second length since that's what you told it to do.

The math that happens so you understand is that you have a start delay of 10s, an end delay of 10s a start cut of 10s and a end cut of 40s. So when calculating the start frame the code first calculates the net start cut value which is startDelay - startCut so in your case 0s becomes the starting value. When calculating the end frame, the end cut value is then calculated by doing -(delayEnd) + endCut which gives you 30s. Hence you get a 30s clip.

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

Please upload it somewhere where I can get it and I'll look into it.

[phate89]

Don't click "original length" in that case then. When you check that option it sets the end delay to the equivalent of your start delay so that length isn't changed. In that example you're cutting out a 30 second segment and it is maintaining that 30 second length since that's what you told it to do.

The math that happens so you understand is that you have a start delay of 10s, an end delay of 10s a start cut of 10s and a end cut of 40s. So when calculating the start frame the code first calculates the net start cut value which is startDelay - startCut so in your case 0s becomes the starting value. When calculating the end frame, the end cut value is then calculated by doing -(delayEnd) + endCut which gives you 30s. Hence you get a 30s clip.



Please upload it somewhere where I can get it and I'll look into it.

I tried without check that. now i get a 40 seconds track... but the start is still the audio i want to cut and not 10 seconds silence...following your formula it will never create the silence if the delay is smaller or equal than the start size...
That formula is based from the assumption that or you add a delay or you do a start cut..
but in a lot of occasions is very useful to do both

example:
in this case i want 10 seconds of silence (delay) and then the second from 10 to 40... for a total of 40 seconds..
with this method it decrease the start point with the delay..but the start point it isn't 0 .. so 10s-10 s=0s and it takes from the start the existing audio....
about the track tomorrow i will upload it to you
about dcaenc.. you think you will be able to use it in the tool? if you don't there's still the option to support like eac3to the surcode dts encode (throug command line i guess)... not free.. not cheap but better than nothing

[tebasuna51]

The math that happens so you understand is that you have a start delay of 10s, an end delay of 10s a start cut of 10s and a end cut of 40s. So when calculating the start frame the code first calculates the net start cut value which is startDelay - startCut so in your case 0s becomes the starting value. When calculating the end frame, the end cut value is then calculated by doing -(delayEnd) + endCut which gives you 30s. Hence you get a 30s clip.

If this is the required behaviour please remove the 'Original Length' check from the Delay box, and put it between 'Cutting' and 'Delay' boxes with a name like 'Preserve Length'

Inside the 'Delay' box seems don't affect to 'Cut' length and the original file length isn't preserved.



in this case i want 10 seconds of silence (delay) and then the second from 10 to 40... for a total of 40 seconds...

All situations can't be solved now without 2 DelayCut pass.
With old/actual DelayCut behaviour you need:

1) Cut your file (10000, 30000)
2) Delay the cut with 10000

[phate89]

All situations can't be solved now without 2 DelayCut pass.
With old/actual DelayCut behaviour you need:

1) Cut your file (10000, 30000)
2) Delay the cut with 10000

Sure i know but it's not how it is supposed to work.. i ask the guy to add a delay and cut at the same time, this is allowed from the gui but it's not what i get..
i think it should be fixed..

[amtm]

So what you want is not a "delay" option but an additional "insert silence" option, correct? This is something we talked about earlier and I will add, but the behavior that happens when you hit "original length" was not changed by me at all. It's the way it has always worked. Other than modifying some data types to get the code to compile in Qt the behavior internal code that calculates target info and does the delaying has not been modified.

about dcaenc.. you think you will be able to use it in the tool? if you don't there's still the option to support like eac3to the surcode dts encode (throug command line i guess)... not free.. not cheap but better than nothing

I would like to but since I'm in the US it will be tricky in getting it pulled down with the executable without running afoul of patent law. The most likely scenario is to dynamically link it and have it pulled down from some other source that I don't host because I'm not going to get myself into legal issues.

[amtm]

If this is the required behaviour please remove the 'Original Length' check from the Delay box, and put it between 'Cutting' and 'Delay' boxes with a name like 'Preserve Length'

Inside the 'Delay' box seems don't affect to 'Cut' length and the original file length isn't preserved.

That sounds like a good idea to change the name of the option since it does seem to be slightly confusing on what it's doing. Also it's not required that that's what happens, but that's just the way jsoto wrote the code to work.


All situations can't be solved now without 2 DelayCut pass.
With old/actual DelayCut behaviour you need:

1) Cut your file (10000, 30000)
2) Delay the cut with 10000

It will be solved by the addition of an "insert silence" feature. Right now, though, I'm trying to nail down if any other bugs exist before I start on the new features.

So outside of the rounding issue that I've locally fixed, the fixcrc cli issue of Selur and phate's issue with a file are there any other bug reports? I will get to all these feature change requests, etc, but I want to make sure all findable bugs are squashed before I start changing more things.

[amtm]

So thinking about this more, what you want phate is for any delay value to be treated as an insert silence? Right now what happens is that if your start frame after all the math is done when calculating the target info is negative it will insert the delay as silence. The problem you see, though, is when you are also cutting within the file and you specify a delay which you expect it to first cut the file then add a delay which should be silence as well, correct? Whereas the longstanding behavior has just been to do the math I showed above which is the startDelay - startCut then it calculates where this is in ac3 frames and if it's not a negative you end up with the audio that precedes your cut point not silence. So would everyone agree with changing the behavior that when you specify a cut and delay value that it does the "cut file first then insert silence at the beginning or end" behavior?

[Selur]

personally I prefer the two pass step, that is necessary atm.
In the GUI it is easy to force this with two radio buttons that let you change values in the cutting OR the delay groupbox and when you hit PROCESS only the values in the enabled groupbox will be used,..

Cu Selur

[amtm]

personally I prefer the two pass step, that is necessary atm.
In the GUI it is easy to force this with two radio buttons that let you change values in the cutting OR the delay groupbox and when you hit PROCESS only the values in the enabled groupbox will be used,..

Cu Selur

Okay, but why is it any better to have to do two processes of

1) Apply cut
2) Apply delay

when the internal code can just be changed to do this all in one pass or transparent to the user as internally two passes? I guess my question is, does anyone actually want the behavior of both a cut and delay to be applied to not insert silence as the delay but instead just have it shift the start and end cut values by the delay values which it currently does? To cut down on unnecessary steps it seems that if you want the 2nd behavior instead of the first that you should just apply a smaller cut value rather than making the 1st case, which I could see more people wanting, to be more complicated than it needs to be.

[phate89]

sent via mp

[Selur]

I'll probably always do it two passes to be sure that I know what is happening. ;)
-> so for me both behaviors are fine, as long as they are documented somehow (maybe a few tooltips?)

[phate89]

So outside of the rounding issue that I've locally fixed, the fixcrc cli issue of Selur and phate's issue with a file are there any other bug reports? I will get to all these feature change requests, etc, but I want to make sure all findable bugs are squashed before I start changing more things.
i sent a mu link with first 30 secs of the ac3 splitted with eac3to.. thanks for looking at it..


I would like to but since I'm in the US it will be tricky in getting it pulled down with the executable without running afoul of patent law. The most likely scenario is to dynamically link it and have it pulled down from some other source that I don't host because I'm not going to get myself into legal issues.
could be a good solution... maybe with dcaenc of this board that LoRd_MuldeR is improving...

So thinking about this more, what you want phate is for any delay value to be treated as an insert silence? Right now what happens is that if your start frame after all the math is done when calculating the target info is negative it will insert the delay as silence. The problem you see, though, is when you are also cutting within the file and you specify a delay which you expect it to first cut the file then add a delay which should be silence as well, correct? Whereas the longstanding behavior has just been to do the math I showed above which is the startDelay - startCut then it calculates where this is in ac3 frames and if it's not a negative you end up with the audio that precedes your cut point not silence. So would everyone agree with changing the behavior that when you specify a cut and delay value that it does the "cut file first then insert silence at the beginning or end" behavior?
I think it's not a new feature, it's not insert silence into track... it's how delay should work.. eac3to and all other tools if you ask them to add delay they add silence.. everywhere delay is silence..
Like it is implemented now what is the purpose? you can get the same exact behaviour easily substracting the delay to the start cut point.. there are 2 methods to do the same thing. and to do a silenced delay there's no way in one pass.. you have to do it twice..

[amtm]

I'll probably always do it two passes to be sure that I know what is happening. ;)
-> so for me both behaviors are fine, as long as they are documented somehow (maybe a few tooltips?)

Yes, I can update the documentation and provide tooltips. Unless someone has a compelling case to the contrary, I'm going to change the behavior as apply cut then insert delay as silence since this seems more logical to me and cuts down on needing extra steps.

[amtm]

i sent a mu link with first 30 secs of the ac3 splitted with eac3to.. thanks for looking at it..

I see that. Thanks a lot!

could be a good solution... maybe with dcaenc of this board that LoRd_MuldeR is improving...

True. It's just going to be tricky on working out how to pull it down without it being to instrusive and annoying to do so.


I think it's not a new feature, it's not insert silence into track... it's how delay should work.. eac3to and all other tools if you ask them to add delay they add silence.. everywhere delay is silence..
Like it is implemented now what is the purpose? you can get the same exact behaviour easily substracting the delay to the start cut point.. there are 2 methods to do the same thing. and to do a silenced delay there's no way in one pass.. you have to do it twice..

I totally agree. :) The current behavior is somewhat illogical since as you and I both state, you should just increase or decrease your cut values rather than using the delay to do this. I agree it's not really a "new feature", my statement was really more of I want to fix any crashing/hanging issues or bugs related to any features I have introduced before changing anything else as I see these as more serious than changing this behavior. But rest assured it will be fixed right after I figure out your and Selur's issues. :)

[phate89]

True. It's just going to be tricky on working out how to pull it down without it being to instrusive and annoying to do so.


i'm not a perfect method but a very basic way you can do it is through command line.. if there's the dcaenc executable in the same folder or in the system environment paths it uses dcaenc.. otherwise it uses the old method..
this is how i used delaycut and eac3to to do my lossless editing tool and where my programming skills finishes :P

[amtm]

i'm not a perfect method but a very basic way you can do it is through command line.. if there's the dcaenc executable in the same folder or in the system environment paths it uses dcaenc.. otherwise it uses the old method..
this is how i used delaycut and eac3to to do my lossless editing tool and where my programming skills finishes :P

Yeah, I'm thinking more of making sure people know to pull down the executable. I can put something in the README but not everyone is going to look at that. The other way would be to have it check and pop up a dialog that it needs to retrieve the file and downloads it at that point with an option to disable the dialog if you don't want to see it again if you check no so it's not a constant nag screen. I guess I can go with the 2nd idea for now.

[phate89]

Yeah, I'm thinking more of making sure people know to pull down the executable. I can put something in the README but not everyone is going to look at that. The other way would be to have it check and pop up a dialog that it needs to retrieve the file and downloads it at that point with an option to disable the dialog if you don't want to see it again if you check no so it's not a constant nag screen. I guess I can go with the 2nd idea for now.

or simply in log you put a WARNING in red telling where they can get the file and where they have to put it...

[amtm]

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

Were you using any specific switches from the CLI? And by "it don't do anything from gui" what does that mean? Having just taken a look at it, I can load it in the GUI and apply delays and cuts and it processes just fine. Same via CLI. Any extra information to help reproduce your crash would be helpful.

[tebasuna51]

...
about dcaenc.. you think you will be able to use it in the tool? if you don't there's still the option to support like eac3to the surcode dts encode (throug command line i guess)... not free.. not cheap but better than nothing

dcaenc can't be used to insert silences in dts's created by Surcode or DTS-HD Master Audio Suite because:

The frame-length created by dcaenc for, 5.1 48 KHz 1536, is 2012 (actual bitrate 1509)
The frame-length created by Surcode/Suite for, 5.1 48 KHz 1536, is 2013 (actual bitrate 1509.75)

The frame-length created by dcaenc for, 5.1 48 KHz 768, is 1008 (actual bitrate 756)
The frame-length created by Surcode/Suite for, 5.1 48 KHz 768, is 1006 (actual bitrate 754.5)

ArcSoft decoder crash when found a frame with different length than first frame (also NicDtsSource crash, libav work without problems).

DelayCut can delay dts's created by Surcode/Suite, but not with dts's created by dcaenc.

[phate89]

Were you using any specific switches from the CLI? And by "it don't do anything from gui" what does that mean? Having just taken a look at it, I can load it in the GUI and apply delays and cuts and it processes just fine. Same via CLI. Any extra information to help reproduce your crash would be helpful.

I try every kind of switch.. It never works.. Everytime i get delaycut.exe stop working from CLI..With the gui even if i don't set anything and i hit process it returns finished with errors (and i get a 0 kbps file)... All other tracks were fine.. I have the same problem with the old 1.3.0

[tebasuna51]

I try every kind of switch.. It never works.. Everytime i get delaycut.exe stop working from CLI..With the gui even if i don't set anything and i hit process it returns finished with errors (and i get a 0 kbps file)... All other tracks were fine.. I have the same problem with the old 1.3.0

The DelayCut log show error messages?

Without problems also here with your sample:

File ........: D:\EPISODIO3.ENG_fixed.AC3
Size ........: 1440768 bytes

----------------------------------------- First Frame Info
SampleRate ..................: 0 (48000 KHz)
BitRate .....................: 14 (384 Kb/s)
Version (bsid) ..............: 8 (Standard)
Bit Stream mode (bsmod) .....: 0 (main audio service: complete main, CM)
Audio coding mode (acmod) ...: 7 (3/2 - L, C, R, SL, SR)
Center Mix Level ............: 0 (0.707, -3.0 dB)
Surround Mix Level ..........: 0 (0.707, -3 dB)
Low frequency effects channel: 1 (Present)
Dialogue normalization ......: - 31 dB
RF atenuattion ..............:-0,28 dB Frame: 1
Languaje ....................: 0 (Not present)
Audio Production Info .......: 0 (Not present)
CopyRight bit ...............: 1
Original bit ................: 1
Timecode1 ...................: 0 (Not present)
Timecode2 ...................: 0 (Not present)
Additional Bsi ..............: 0 (Not present)
Block switch flags ..........: 0
Dither flags ................: 31
Dynamic Range Info ..........: 0 (Not present)
--------------------------------------------- Revised Info
RF Ov. Pr. min/max : -4,54 / 0,52 dB
Dyn. Range min/max : -4,54 / 0,26 dB
Total Frames ......: 938
Duration ..........: 30,016 seconds. ( 0 h. 0 m. 30,016 s.)
------------------------------------------------- End Info

If you cut the ac3 file maybe the problem is after than the first 938 frames.

[phate89]

The DelayCut log show error messages?

If you cut the ac3 file maybe the problem is after than the first 938 frames.

here it is the log file:

[Input info]
Bitrate=384
Actual rate=384
Sampling Frec=48000
TotalFrames=938
Bytesperframe=1536.0000
Filesize=1440768
FrameDuration= 32.0000
Framespersecond= 31.2500
Duration=00:00:30.016
Channels mode=3/2: L+C+R+SL+SR
LFE=LFE: Present
[Target info]
StartFrame=0
EndFrame=937
NotFixedDelay= 0.0000
Duration=00:00:30.016

it don't show errors..even just processing throws error.. i'm quite sure during the execution the process throw an exception not handled and stop working...
because if i run via command line the process crashes and windows shows me... instead if i run it from the gui the exception is catched..
it only happens in 1.4.3.3.. with 1.3.0 it works well..
i'm downloading qt sdk to see if i can load it in vs and find out the error..

[amtm]

The processing code doesn't even use exceptions so it's not a case of exceptions being thrown and either not caught or being caught and suppressed. Do you possibly get a crash dump when the GUI crashes? Without more information or a sample that can reliable reproduce there's not much I can do.

[amtm]

dcaenc can't be used to insert silences in dts's created by Surcode or DTS-HD Master Audio Suite because:

The frame-length created by dcaenc for, 5.1 48 KHz 1536, is 2012 (actual bitrate 1509)
The frame-length created by Surcode/Suite for, 5.1 48 KHz 1536, is 2013 (actual bitrate 1509.75)

The frame-length created by dcaenc for, 5.1 48 KHz 768, is 1008 (actual bitrate 756)
The frame-length created by Surcode/Suite for, 5.1 48 KHz 768, is 1006 (actual bitrate 754.5)

ArcSoft decoder crash when found a frame with different length than first frame (also NicDtsSource crash, libav work without problems).

DelayCut can delay dts's created by Surcode/Suite, but not with dts's created by dcaenc.

Well then what I may just have to do is create that "truckload" of silent frames if dcaenc won't work or just create only those silent frames that match the formats supported by DVD/BD and just warn that for any other bitrate/sampling rate/channel mapping that you may end up with a non-compliant stream. Right now it just has the 768kbit/48k 6 channel and 1536kbit/48k 6 channel frames. I have access to surcode so it wouldn't be hard to generate silence frames to match all other DVD/BD supported formats. That's a shame, too. Still an interesting encoder, though.

[phate89]

The processing code doesn't even use exceptions so it's not a case of exceptions being thrown and either not caught or being caught and suppressed. Do you possibly get a crash dump when the GUI crashes? Without more information or a sample that can reliable reproduce there's not much I can do.

the strange thing is that the guy don't crash... it only crash through command line... but from the gui still not work..i can try to debug if i understand how qt works.. i installed the libraries for vs 2010 but i don't know how to compile it..

[amtm]

the strange thing is that the guy don't crash... it only crash through command line... but from the gui still not work..i can try to debug if i understand how qt works.. i installed the libraries for vs 2010 but i don't know how to compile it..

Do you see in errors in the info window when you load it? What does the GUI do when you click process? If you need you might have to post the whole file because that sample doesn't trigger anything. I really want to help you, but I'm lost on my end in reproducing. Using it through CLI that sample processes just fine and I get a fixed file just like through the GUI.

[phate89]

Do you see in errors in the info window when you load it? What does the GUI do when you click process? If you need you might have to post the whole file because that sample doesn't trigger anything. I really want to help you, but I'm lost on my end in reproducing. Using it through CLI that sample processes just fine and I get a fixed file just like through the GUI.

it doesn't show anything..
====== INPUT FILE INFO ===============
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 1440768
Channels mode 3/2: L+C+R+SL+SR
Sampling Frec 48000
Low Frec Effects LFE: Present
Duration 00:00:30.016
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 938
Bytes per Frame 1536.0000
Size % Framesize 0
CRC present: YES
======================================
====== TARGET FILE INFO ==============
Start Frame 0
End Frame 937
Num of Frames 938
Duration 00:00:30.016
NotFixedDelay 0.0000
======================================


post the whole file is pointless because the split too doesn't work..
I'm trying to make vs 2010 work with qt so i can run it and debug it...

[amtm]

it doesn't show anything..
====== INPUT FILE INFO ===============
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 1440768
Channels mode 3/2: L+C+R+SL+SR
Sampling Frec 48000
Low Frec Effects LFE: Present
Duration 00:00:30.016
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 938
Bytes per Frame 1536.0000
Size % Framesize 0
CRC present: YES
======================================
====== TARGET FILE INFO ==============
Start Frame 0
End Frame 937
Num of Frames 938
Duration 00:00:30.016
NotFixedDelay 0.0000
======================================


post the whole file is pointless because the split too doesn't work..
I'm trying to make vs 2010 work with qt so i can run it and debug it...

If you're going to use my solution file that you can pull down from Github you're going to want to also install the Qt VS Add-in so you can easily select your Qt version and you'll need to create static versions of the Qt DLLs which means you're going to have to compile Qt yourself from source.

[phate89]

If you're going to use my solution file that you can pull down from Github you're going to want to also install the Qt VS Add-in so you can easily select your Qt version and you'll need to create static versions of the Qt DLLs which means you're going to have to compile Qt yourself from source.
Yes it's what i'm trying to do but i'm facing some problem..
to start i post the signature problem:
Firma problema:
Nome evento problema: BEX
Nome applicazione: delaycut.exe
Versione applicazione: 0.0.0.0
Timestamp applicazione: 4ef6b089
Nome modulo con errori: delaycut.exe
Versione modulo con errori: 0.0.0.0
Timestamp modulo con errori: 4ef6b089
Offset eccezione: 0034a492
Codice eccezione: c0000417
Dati eccezione: 00000000
Versione SO: 6.1.7601.2.1.0.768.3
ID impostazioni locali: 1040
Informazioni aggiuntive 1: 88c9
Ulteriori informazioni 2: 88c9433e6e1867c48044b21b30a886fd
Ulteriori informazioni 3: f92d
Ulteriori informazioni 4: f92d850d12d5d20a2d5297523b602f30



maybe you can do an executable to me to find out exactly where the process crash..

[XMEN3]

Adding frames to dts (Bluray 768) makes the file incompatibile with avisynth (behappy) and arcsoft (eac3to).
The file is played fine with foobar (dts.dll) and decoded fine with libav (eac3to).
Dunno if using behappy the problem is avisynth or nicaudio.
Anyway the original dts is decoded fine from every filter before using delaycut to fix missing frames.
This append also with old delaycut 1.3.1.0

Starting job test.dts->test.ac3
Found Audio Stream
Channels=6, BitsPerSample=32 float, SampleRate=48000Hz
encoder\Aften.exe -v 0 -b 448 -m 0 -readtoeof 1 -cmix 0 -smix 0 -dsur 0 -dnorm 31 -dynrng 5 -w 48 - "F:\test.ac3"
Writing RIFF header to encoder's StdIn
Writing PCM data to encoder's StdIn
Error: BeHappy.AviSynthException: m2AudioDTSSource: error in file "F:\test.dts"
at BeHappy.Encoder.encode()

Also less important...
A missing one from old delaycut is drag and drop.

thanks