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

[amtm]

I have ported delaycut from MFC to Qt and am at a point to release it as a beta to get others to test it.

Source code is at: https://github.com/athomasm/delaycut

Any feedback, bug reports, requests are welcome.

Version 1.4.1.0
- Added back CLI support.

Version 1.4.2.0
-Fix crash for opening file names with Unicode characters.

Version 1.4.3.0
- Add option to select input type between milliseconds, seconds, frames. Can add both rational values (24000/1001) or decimal (23.976) values in FPS field.
- Removed debug info being displayed in message box that was accidently left in.
- Added CLI switches to support new input value types.

Version 1.4.3.1
- Fix so that delay fields properly accept negative values.
- Fix for math when using frames as input type.

Version 1.4.3.2
- Fix autodelay detection so that it converts ms value in fileName to the selected input type.
- Fixed bugs in converting values between different input types.
- Fixed math errors when specifying delay in frames.
- Fixed bug where output file path wasn't updated when using Save As dialog.

Version 1.4.3.4.
-Fix rounding when converting between input types to a round half up scheme. Also changed the calculations for start and end frame to use the same.
-Fixed check for enabling the CRC group edit so it enables properly.
-Fix bug that where a pathological file caused the processing to never finish and UI hang.
-Calculated end frame is capped to the total frames in cases where end split value specified exceeds length of file.
-Renamed "original length" field to "preserve length".
-End cut value of 0 is treated as end of file when calculating end frame.
-End cut and start cut values no longer cause the other field to be overwritten. All checks to make sure that end cut is not smaller than start cut, except for the case of 0, happens when process button is clicked.

Version 1.4.3.5
-Logging of progress and error messages when using the CLI have been added back.
- "-console" switch has been removed. Switches to specify cut points have been renamed to "-startcut" and "-endcut" respectively. Switches to specify delay values have been renmaed to "-startdelay" and "-enddelay" respectively. "-i" switch introduced to allow the specifying of the input file path anywhere in the CLI arguments. "-version" switches introduced to get the current version of the software.

Version 1.4.3.6
-Added support to specify delay/cut values in audio frames.
-Added "-help" switch to display the options available from CLI.
-Fixed so that delay field in GUI worked properly.
-Fixed CLI parser for to detect new switches.

Version 1.4.3.7 ( http://www.videohelp.com/download/delaycut1.4.3.7.7z)
-Fixed logic bug when checking valid input types.
-Fixed output of -help and the README to the proper names of the new switches.

Usage:

Command Line Instructions
Output and log files will be in the same path than the input file.

Options:
-help: List options.
-version: Get current version.
-info: Outputs info about input file in log file
-inputtype <string>: Input type of delay/cut values. (default millseconds
when not specified) [milliseconds, seconds, videoframes]
-fps <float|rational>: Specify frame rate.
Needed when inputtype is set to frames.
-fixcrc <string>: Specify action to take in the case of crc errors
[ignore, skip, fix, silence]
-startdelay <integer>: Specify the needed frames added at the beginning of the file
-enddelay<integer>: Specify the needed frames added at the end of the file
-same: file length will be the same after adding delay
-auto: detect start delay in filename (assuming DVD2AVI style)
-startcut <integer>: Specify cut start point
-endcut <integer>: Specify cut end point
-o <string>: specify output file
-i <string>: specify inputfile

Return values
0: Success
1: Something went wrong.

Examples:
Get info: Log file will be myfile_log.txt
delaycut -info -i myfile.ac3

Adds 100 msec of silence at the begining. File lenght will be the same
delaycut -startdelay 100 -same -i myfile.ac3

Adds 100 msec of silence at the begining. File lenght will be 100 msecs more
delaycut -startdelay 100 -i myfile.ac3

Cuts start at 10.32 sec and ends at 15.20 sec.
delaycut -inputtype seconds -startcut 10.32 -endcut 15.20 -i myfile.ac3

Cuts start at 10320 msec and ends at 15200 msec. Delay correction of 100 msec.
delaycut -startdelay 100 -startcut 10320 -endcut 15200 -i myfile.ac3

[b66pak]

thanks a lot...
_

[amtm]

You're welcome. I'm not sure how many people still use it, but it was a simple enough app that I've been working on to learn Qt and get back into C++. After I get the CLI part reimplemented and some refactoring done tonight (since the old delaycut code was just a quick and dirty import and get it compiling job) and no one mentions any major bugs I'll push it out as a real release.

As far as I can tell from my so far limited testing file output is identical to the last delaycut release (verified with sha-1 hashes).

[Thunderbolt8]

not sure whether I understand, but version 1.3.0.0 does already exist, madshi made that one.

so whats the difference here?

[amtm]

I didn't know he had I just diverged from the last version from jsoto's site. This is different in that it's written in Qt so it's cross-platform. And I'll change the version number. Can you link his version? I'd love to incorporate any changes he made

[amtm]

Never mind I found madshi's version. When I get home I'll incorporate his changes and change the version number.

[Thunderbolt8]

so what exactly are your changes? (in case you stated them above, I cant understand that, sorry :D )

[amtm]

Its rewritten in Qt to be cross-platform, for those who care, and when I'm done tonight a significantly cleaned up codebase. At that point more functionality, etc can be added per any requests, etc.

As I said above this is mostly for me learning Qt and getting back into c++ programming. I thought I'd share in case anyone else was interested.

[amtm]

Plus I know there are other tools that do the same thing but none are as simple to use as this, IMO, so I thought I'd try to revive it. It's just one of a number of older mfc-based tools I've been working on porting.

[shh]

Win7x64: I click "Browse" for an input file, then break (don't select anything) -> crash

[amtm]

Ok, I see the issue. Fixing now. Fix will be in the newest version with the eac3 support. Removing the download link till I get the new version up.

[amtm]

New version renamed to 1.4 beta is ready to grab here (https://github.com/downloads/athomasm/delaycut/delaycut.exe).

This has the file dialog fix, adds eac3 support from madshi's 1.3.0.0 and adds support to autofill delay values set in the file that Chumbo added in 1.3.1.0.

Working on getting LiveCDs for Debian and Ubuntu to get generate deb packages for Debian 6, and Ubuntu 11.04 and 11.10. Will update when they are created.

[Sparktank]

Neat!

Any chance of adding more file support?
Like the lossless streams: DTSHD-MA, Dolby TrueHD, FLAC, w64?

Would come in handy when editing isolated scores from Blu-Ray.

[amtm]

Sure, I'll add it into the TODO list.

[Sparktank]

Sure, I'll add it into the TODO list.

:thanks:
There's no rep or thanks buttons in doom9 :p

[amtm]

Version 1.4.0.0 available for download here: https://github.com/downloads/athomasm/delaycut/delaycut1.4.0.0.zip

Linux binaries later tonight.

[amtm]

For anyone who cares I have binaries here (https://build.opensuse.org/package/show?package=delaycut&project=home%3Aamtm) for Linux. Builds include Debian 5 & 6, Ubuntu 9.10 - 11.10, OpenSuSE 11.3-4, 12.1, Factory and Tumbleweed, and Fedora 15/16.

[pandv2]

It's the cli part implemented? I tried -info and the gui appears.

Thank's.

[amtm]

I've got it implemented locally just not pushed yet. I'll have it in tonight and new binaries.

[amtm]

Version with CLI support back in: https://github.com/downloads/athomasm/delaycut/delaycut1.4.1.0.7z

Additional items still on the TODO list will be worked on but I will be busy the next couple of days so it probably won't be a new version until next week.

[amtm]

A question for users. On videohelp forums someone wanted to have the delay and cut fields support input values in seconds. I was thinking of having the user type s at the end to let the program know that the value isn't milliseconds and without that it just defaults to the normal behavior. Does that sound okay?

[TDiTP_]

delaycut v1.4.1.0 is crash when i use Cyrillic letters in the file name. Version 1.3.1.0 works fine.

Does that sound okay?
Yes :)

[amtm]

Ok. I know what the issue is. I'll push a fix and a new build in a while.

[Stereodude]

How about allowing video frame numbers to be used instead of time? ie: Have a drop down or field to enter a video frame rate, and then allow entry of video frame numbers. I use DelayCut quite a bit lately, but I'm always dealing with frame numbers in my AVIsynth scripts and it's a pain to have to turn them into time values in Excel and then enter them into DelayCut.

[amtm]

Yeah I can do that since this should be easy and I'll try to get this and the filename crash fix in tonight. To support it for the CLI I can also add an -fps switch.

[Sparktank]

Neat. I like that variety of using ms/s/frame numbers.
i wish there was a calculator specifically for time. so many programs require just one format and never really know other formats.
i don't have excel so I do it all with a calculator and .txt pad open.
([frame rate](24000/1001)*60[seconds]*[number of minutes i want]+[left over Second.milliseconds] :( my head hurts)

[Stereodude]

Yeah I can do that since this should be easy and I'll try to get this and the filename crash fix in tonight. To support it for the CLI I can also add an -fps switch.Thanks! Looking forward to it.

[amtm]

So I didn't have any time to work on this last night but I had enough time this morning to push the bug fix that TDiTP_ reported. The new version can be had here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.2.0.7z). I created a file with Cyrillic characters and it opened fine. Please report if you have any other issues.

[amtm]

New version here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.0.7z). Has the selectable input type between milliseconds, seconds, frames. Apparently I forgot to disable a messagebox I was using for debugging so that has been disabled.

[amtm]

Also, there are Linux packages being rebuilt here (https://build.opensuse.org/package/show?package=delaycut&project=home%3Aamtm) for anyone interested.

[amtm]

The github download link appears to not be working. When I get home I'll post the binary to something like megaupload.

Also the deb packages from that opensuse build link is also broken. I'll fix that too tonight. Argh.

[b66pak]

please use m u l t i u p l o a d . c o m
_

[amtm]

Ok will do.

[Sparktank]

O_O I can't wait for a working link!
"input type between milliseconds, seconds, frames"
http://media.tumblr.com/tumblr_lcwyynageD1qzr2th.gif

[amtm]

I'm heading home soon. So check back in like an hour or so.

[amtm]

File reuploaded to github here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.0.7z). Mirror is also here (http://www.multiupload.com/E9W51IOUC2). Added explanation of new CLI switches in the README.txt file.

To clarify, in the FPS field you can also specify rational values like 24000/1001 or just the normal decimal value like 23.976.

[Sparktank]

ty, tyvm!

[Stereodude]

Thanks for the version with video frame based. However, I've already discovered a shortcoming in use. AC3 files when spit out of DGIndex has a ms delay in the file name like PID 014 3_2ch 384Kbps DELAY 596ms.ac3. That delay positive or negative is how much extra or short the audio is from being in sync with the video stream. It would be nice to be able to have a "File Offset" (or equivalent function) field that accepts positive and negative values in ms (perhaps even reading the file name to auto populate it) even if I'm working in frames so I can line up the audio and video with it and then work on a time or frame basis using video derived values. Otherwise I have to make 2 passes (first to remove or add audio to account for the offset and a 2nd to trim to match the video) or go back to doing math converting frames to time or convert time to frames.

Thanks. Sorry for being a hard to please whiner. :)

[amtm]

If the delay fields aren't accepting a negative value then it's a bug. Because it should as the original did.

[amtm]

I see the issue and pushing a fix. The QValidator for the delay field was given 0 as the minimum value when it was meant to be the lowest negative value. Recompiling a new version.

[Stereodude]

If the delay fields aren't accepting a negative value then it's a bug. Because it should as the original did.FWIW, I can't put negative values in any of the fields when selecting milliseconds, however that wasn't my request in my last post. I want a way to account for the underlined delay while still staying in frames.

http://img823.imageshack.us/img823/6052/dcissue1.png

Also, the math seems incorrect. In my screenshot a start point of 708 frames at 30000/1001 (29.97...) should be a start of 23624ms or 738 AC3 frames and the end should be end of 197531ms or 6173 AC3 frames for a length of 173907ms or 5435 AC3 frames.

[amtm]

Ok, looking into that too. Thanks for the feedback.

[Stereodude]

Ok, looking into that too. Thanks for the feedback.FWIW, it looks like it is still treating the video frames as ms.

[amtm]

Internally, yes it does convert to ms. That's because how the original code works. But the conversion values are correct now if you use frames in 1.4.3.1. I get the expected values when trying to reproduce your example above in it. It also fixes the negative delay not getting accepted bug.

Just to make it visible in case someone hasn't read the first post the new version is here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.1.7z). Mirrored version can be found here (http://www.multiupload.com/DQ5W2XSFJX).

[amtm]

Oh, I see your point about the frames issue when used for delay. I missed the part about you mentioning it in reference to the detected delay in the filename and having that converted into frames if that option is selected. I also noticed an issue where inputting delay values in frames causes wildly incorrect values to appear under the target info. I know the issue in both cases and can have fixes tonight when I get home. This should hopefully be the last update needed to get the alternate modes fully working.

[Stereodude]

FWIW, my thought was to have a "Starting Offset" or "File Start Time Offset" field added under the input file where the positive or negative delay could be auto read / manually entered keeping it away from the other fields.

like this:
http://img14.imageshack.us/img14/4442/dcsuggestion01.png

PS: Thanks for considering user feedback and making improvements to DelayCut.

[amtm]

But the delay from the file is already read and auto-populated into the start delay field. Why the need for a second field that does the same thing? If you need additional negative or positive value delay on top of what is read in, why not just modify the value in that start field? That's ultimately what would happen behind the scenes anyway if there was a second field.

[Stereodude]

But the delay from the file is already read and auto-populated into the start delay field. Why the need for a second field that does the same thing?It is? I haven't noticed.
If you need additional negative or positive value delay on top of what is read in, why not just modify the value in that start field? That's ultimately what would happen behind the scenes anyway if there was a second field.I guess I'll have to try it again later when I'm home. If it already goes into the delay start field, then you're right it's not needed.

[amtm]

It is? I haven't noticed.

Yeah, the code to do so was added in and working for the 1.4.0.0 version. I just tested again with the latest 1.4.3.1 with a file I have by adding "DELAY 182ms" to the end of the filename and it populates correctly.

I guess I'll have to try it again later when I'm home. If it already goes into the delay start field, then you're right it's not needed.

Yeah, if it's not doing so something is wrong. Like I said, it seems to work fine for me with the latest 1.4.3.1. So if you can test with that version and you get something different, I'd love to know.

[Motenai Yoda]

If possible, can zero refers to "the end of file" in the cutting end field? (like in avisynth's trim)
I'm boring to calculate it every-times.

edit:-
also save with other name is impossible, even changing path in the field, even with the "save as" windows too.
edit2:-
it saves where it decides.

[tebasuna51]

If possible, can zero refers to "the end of file" in the cutting end field? (like in avisynth's trim)
I'm boring to calculate it every-times.

Use 'Delay' box instead 'Cutting'

[Stereodude]

Yeah, if it's not doing so something is wrong. Like I said, it seems to work fine for me with the latest 1.4.3.1. So if you can test with that version and you get something different, I'd love to know.Okay, this part seems to work fine. I guess I didn't realize that's what it was doing before.

I will await a bugfix for loopy math that spits out really large negative numbers.

[amtm]

edit:-
also save with other name is impossible, even changing path in the field, even with the "save as" windows too.
edit2:-
it saves where it decides.

I found the issue with it not changing the path when you use the save as screen. But when I edit the filepath in the edit field directory it saves just fine to the alternate directory. Does it popup an error for you?

Okay, this part seems to work fine. I guess I didn't realize that's what it was doing before.

I will await a bugfix for loopy math that spits out really large negative numbers.

I've fixed all the bugs. Just doing a bunch more regression testing to make sure nothing new pops up. Sorry for the wait. :o

[amtm]

Okay. Everything is tested and all bugs I can find appear to be fixed. Please give it more testing the feedback has been great. :)

Download here (http://www.videohelp.com/tools?d=delaycut1.4.3.2.zip ) or here (http://www.multiupload.com/WZF4NTJWJQ).

[Stereodude]

Okay. Everything is tested and all bugs I can find appear to be fixed. Please give it more testing the feedback has been great. :)

Download here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.2.7z) or here (http://www.multiupload.com/WZF4NTJWJQ).It seems to be working for me as expected.

I have one more complaint about the way it works (the old version did it too). In the Cut file area when you enter a value in the start field and then select the end field and type in the end value it deletes the value you just entered in the start and changes it to the first number of the start value. I believe it's because it updates / recalculates after every key stroke and since you can't have the start value after the end value so it sets the start value to the end value which is just 1 number long as you're typing it.

I made a picture to help describe the issue.
http://img843.imageshack.us/img843/1752/dcissue2.th.png (http://img843.imageshack.us/img843/1752/dcissue2.png)

[phate89]

hi.. i always use the old 1.2.1.2 version.. yesterday i see this new version and tried it... but my usual script doesn't work...

i use to insert silence or cut parts in an ac3 file.. so i cut in 2 parts the file and i add the delay to the 2nd part to join them after...
i usually use this script:
delaycut -endsplit 800.611 audio.ac3
delaycut -start 3120 -startsplit 800.611 audio.ac3

usually this script create the first file with audio from the start to 800.611 and create the second file with the silence at start and the audio from 800.611 to the end...

with this new version the first line runs... but it creates a copy of the original file without cuts... the second it don't work at all.. if i don't insert a -endsplit it doesn't run... can you fix it?

[tebasuna51]

I have one more complaint about the way it works (the old version did it too). In the Cut file area when you enter a value in the start field and then select the end field and type in the end value it deletes the value you just entered in the start and changes it to the first number of the start value. I believe it's because it updates / recalculates after every key stroke and since you can't have the start value after the end value so it sets the start value to the end value which is just 1 number long as you're typing it.

Simple, fill the 'end' value before the 'start' value.
Experienced DelayCut users always do this.

[Stereodude]

Simple, fill the 'end' value before the 'start' value.
Experienced DelayCut users always do this.Yes, I realize this is a workaround however, IMHO, it shouldn't be necessary.

[amtm]

hi.. i always use the old 1.2.1.2 version.. yesterday i see this new version and tried it... but my usual script doesn't work...

i use to insert silence or cut parts in an ac3 file.. so i cut in 2 parts the file and i add the delay to the 2nd part to join them after...
i usually use this script:
delaycut -endsplit 800.611 audio.ac3
delaycut -start 3120 -startsplit 800.611 audio.ac3

usually this script create the first file with audio from the start to 800.611 and create the second file with the silence at start and the audio from 800.611 to the end...

with this new version the first line runs... but it creates a copy of the original file without cuts... the second it don't work at all.. if i don't insert a -endsplit it doesn't run... can you fix it?

I'll look into it.

To stereodude, yeah I can change it so it just does the check for end cut < start cut when you hit process and will popup an error message. I didn't really like that it did that either I was just mimicking the old behavior so I'm fine with changing it.

[Stereodude]

To stereodude, yeah I can change it so it just does the check for end cut < start cut when you hit process and will popup an error message. I didn't really like that it did that either I was just mimicking the old behavior so I'm fine with changing it.Glad to know I wasn't the only person not thrilled with that aspect. Is it possible to have it check after you click out of that field (having typed the full number)? If not checking when you hit process would be cool also.

[amtm]

Yeah I'll see which one appears less annoying. Also if you have any other feedback please feel free to keep the ideas coming. I'm more than happy to make tweaks to make the tool better.

[phate89]

amtm did you ever think to improve the tool allowing insert silence or cut audio inside the file?
you add the points in the audio and the operations (add silence, remove audio, loop the audio) and he make all the changes in one pass...complete basic editing without recompression...
there's nothing like this... eac3to allows to insert silence or remove audio in track but only one for pass (so with 5 editing i have to recreate 5 times the full file), your tool allows cuts and delay but no insert or cut in the middle, besplit only split the file in parts...
I already create my own program to do that based on this tool but everytime i have to split & then join increasing the time and i can't compensate the not fixed delay...
naturally it's not so easy to do but it could be a very useful tool... perfect for me... if you have time think about it...i try to look into the code but it's too much for my skills :(

[TDiTP_]

One thought about delaycut vs eac3to.


eac3to can not "create" new silent DTS frames which are needed for delay. Instead eac3to simply repeats the very first frame of the audio track as often as necessary to achieve the wanted delay. Normally a DVD audio track begins silent, so this usually works. If your DVD audio track begins non-silent, then eac3to's way of delaying isn't silent, but results in ugly noise, sadly. If there was a free DTS encoder available, I could solve this, but there isn't. For AC3 I'm using Aften to do the audio delay properly and guaranteed-noise-free.

delaycut can do this better, but since it doesn't have a DTS encoder, either, it simply uses a default silent DTS frame - which doesn't have the DTS-ES flag set, of course.

I can add. Delaycut can add "standart" DTS frames only (they are use on DVD; 1006 against 1024 "bytes per frame" for 768) and if we add such frame to DTS from Blu-ray, then eac3to with ArcSoft/Sonic/Nero will not be able to decode it (but libav can). => we can't use it to work with DTS from Blu-ray.

For example. Look at this (http://www.mediafire.com/?ees21hdwd9nzw1b) stream from BD. Try to decode it (by ArcSoft/Sonic/Nero) and then using delaycut add delay and retry decode. Then cut delay and retry again :)

Can you add Blu-ray's dts frames to "default silent DTS frame" of delaycut?

[Midzuki]

^ @ TDiTP_

«Normal» :) "Blu-Ray DTS" can be anywhere between 1.0@192kbps and 5.1@1509kbps. So, delaycut would have to be shipped together with a "small truckload" :) of "silent DTS sample files" :confused: :confused: :confused:

[TDiTP_]

«Normal» "Blu-Ray DTS" can be anywhere between 1.0@192kbps and 5.1@1509kbps
Yes :) (and 5.1@1510kbps can be too).

Addition to my previous post. If we talking about "Targeted BitRate"=1536:
1). Most of "Blu-ray DTS" (all that i saw, but can be exceptions) have 2012 bytes per frame.
2). All "core DTS" have 2012 bytes per frame. This is most important. At least for this we must have support for such frames in delaycut, which can add only 2013.
3). In DTS-HD M.A.S. when we select "Destination Format = DVD (.cpt)" we always get 2013 bytes per frame. If "Destination Format = Blu-ray disc (.dtshd)" we always get 2012 bytes per frame (in dts or "core dts").

[Stereodude]

I found another couple of bugs.

1) Changes to the video FPS field don't cause the program to recalculate unless you change another field or change an checkbox.
2) The starting offset delay doesn't re-autopopulate / recalculate if re-opening the same file or changing the FPS.
3) Changing from frames to ms causes the starting offset delay to decrease each time you switch
4) The starting offset delay isn't subtracted from the cut file End setting so the output audio is too long

[sl1pkn07]

i have problems build in my archlinux


sl1pkn07@sL1pKn07 delaycut $ qmake -makefile delaycut.pro
sl1pkn07@sL1pKn07 delaycut $ make
g++ -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -Wl,-O1 -o delaycut -L/usr/lib -lQtGui -lQtCore -lpthread
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld devolvió el estado de salida 1
make: *** [delaycut] Error 1
sl1pkn07@sL1pKn07 delaycut $

[amtm]

Sorry, I've been away for a bit. Will address the bugs this weekend. sl1pkn07 your build problems are due to their being two different configs in the pro file. You need to add a CONFIG+=Linux on your qmake line. I'll update the readme with information about building from source so that's more obvious.

[sl1pkn07]

oh! thanks

[Stereodude]

Sorry, I've been away for a bit.We were about to send out search parties. :scared:

[phate89]

Sorry, I've been away for a bit. Will address the bugs this weekend. sl1pkn07 your build problems are due to their being two different configs in the pro file. You need to add a CONFIG+=Linux on your qmake line. I'll update the readme with information about building from source so that's more obvious.

don't worry take your time...
you think it's possible to make a program like the one i described before? i'm trying to look at the C++ code to understand how it works and try to do it myself but is far too adanced for me... the first problem is that i have no clue how are composed the files...
You think it's theorically possible?

[amtm]

Yeah it can be done. I'm just trying to work out the best way to implement it.

[phate89]

Yeah it can be done. I'm just trying to work out the best way to implement it.
UUh great! :D
Unother idea that could be useful in that program is a loop flag.... if there's the loop flag in that edit instead of inserting some silence it repeat the previous frames...

[tebasuna51]

Another suggestion to DelayCut improvment.

If we have a ac3 file with mixed content (for instance a TV capture with 5.1 frames from a movie and 2.0 frames from commercials), DelayCut show a message like:
Time 00:00:20.032; Frame#= 627. Some basic parameters changed between Frame #1 and this frame

But the output file remains invalid (a valid ac3 stream must contain only the same frametypes).
Also the 'Num of frames' and 'Duration' are incorrect because the 'FrameSize' change.

I suggest a flag with 3 options:

1) Ignore FrameType changes (like now)
2) Extract only frames like first FrameType.
3) Extract only 5.1 frames.

[phate89]

Another suggestion to DelayCut improvment.

If we have a ac3 file with mixed content (for instance a TV capture with 5.1 frames from a movie and 2.0 frames from commercials), DelayCut show a message like:
Time 00:00:20.032; Frame#= 627. Some basic parameters changed between Frame #1 and this frame

But the output file remains invalid (a valid ac3 stream must contain only the same frametypes).
Also the 'Num of frames' and 'Duration' are incorrect because the 'FrameSize' change.

I suggest a flag with 3 options:

1) Ignore FrameType changes (like now)
2) Extract only frames like first FrameType.
3) Extract only 5.1 frames.

very good idea...could be a easy way to remove ads too!
usually ads are 2.0 so will be removed automatically

[amtm]

Sorry guys I've been really bad about getting back to this. I've have written down all the suggestions on my TODO list. I really hope to get a new version out this weekend that at least addresses the last couple of bug reports before I get into implementing those new features. Just want to let you know that I am still monitoring this. The time leading up to this holiday has just been rather crazy.

[pandv2]

I searched long time for a tool to add silence and cut as described by phate89. Now I am using besplit to break the ac3 in parts, ac3to to add delay to each part o cut the beginning and ac3to to rejoin the fragments. It's automated (so, no extra work), but it's ugly.

And let me add another option to tebasuna51 flag to deal with mixed ac3 frames:

4) Force the track to be 5.1 or 2.0 (dropping channels or adding silence channels). It this is not possible without reencode, forget it.

And, please, rememeber to add the new options to command line.

Thanks for your work, and don't worry about time.

[tebasuna51]

...
4) Force the track to be 5.1 or 2.0 (dropping channels or adding silence channels). It this is not possible without reencode, forget it.

Yes, is not possible without reencode.

[phate89]

Yes, is not possible without reencode.

it's not possible to do it reencoding only the necessary frames? i don't know very well ac3 structure. in theory should be possible?

[tebasuna51]

it's not possible to do it reencoding only the necessary frames? i don't know very well ac3 structure. in theory should be possible?
You need split, decode, edit, recode and join.
To much job for a useless, for me, output.

[phate89]

You need split, decode, edit, recode and join.
To much job for a useless, for me, output.

yes but if he adds it in the program it's not so much job.. the program copies the 5.1 frames, when it found a different frame it converts it..
in my case could be useful.. usually a frends pass me it's 5.1 recorded audio that i edit to sync with eac3to... but where it cuts for the commercial he leave some 2.0 silence frame.. and that frames create a lot of problems with lossless editing because there are frame of different sizes.. i could remove the 2.0 frames but then i will loose the silence between the 2 parts and the timing will be different (... naturally it's a rare case but could be useful..

[tebasuna51]

yes but if he adds it in the program it's not so much job.. the program copies the 5.1 frames, when it found a different frame it converts it...

Not so much job?
Must add a decoder and a encoder to delaycut to create 2.0 to 5.1 frames than must be cut after.

I think is better remove the 2.0 frames and cut the video with these cut points (maybe with some delay). The sync, and the silence between the 2 parts, must be preserved.

[amtm]

Yeah adding such a feature would really make the tool more complex than I want it to stay at. I think the tool should really stay as a one for losslessly cutting and delaying audio streams. When things start getting into needing to decode, reencode, etc the streams that really starts getting outside of the core focus of the tool. I know it's sometimes a pain to use multiple tools, but there are already good, mature tools to do things like converting from 5.1 to 2.0 and those should be leveraged instead of reinventing the wheel so that this tool does that as well.

BTW, just so any new bug reports don't get lost in the thread, if you could open up issues here (https://github.com/athomasm/delaycut/issues) so that they can be more easily tracked that would be quite helpful. Thanks! I'll take care of creating issues for those things already reported.

[amtm]

Also in regards to the issue with adding silence frames to DTS I've found an open source DTS encoder here (http://patrakov.blogspot.com/2011/09/i-wrote-dts-encoder.html) that is supposed to make compliant streams that could possibly be used to create silence frames that will be decodable by more than just libavcodec. The only issue will be with the patent issues with bundling that with my app since I do live in the US and there would be issues. I'm going to investigate it maybe next week or so to see if it can be useful and how it can be distributed with the application so I don't face any legal issues from DTS, Inc. coming down on my head.

[phate89]

Yeah adding such a feature would really make the tool more complex than I want it to stay at. I think the tool should really stay as a one for losslessly cutting and delaying audio streams. When things start getting into needing to decode, reencode, etc the streams that really starts getting outside of the core focus of the tool. I know it's sometimes a pain to use multiple tools, but there are already good, mature tools to do things like converting from 5.1 to 2.0 and those should be leveraged instead of reinventing the wheel so that this tool does that as well.

Not so much job?
Must add a decoder and a encoder to delaycut to create 2.0 to 5.1 frames than must be cut after.

I think is better remove the 2.0 frames and cut the video with these cut points (maybe with some delay). The sync, and the silence between the 2 parts, must be preserved.

an equal good solution is instead of reencoding an option to simply replace 2.0 audio with empty frames solving the problem..
btw it's for sure something less important and there are a lot of things to address before...
one of the most important is for sure dts delays...

[Selur]

Is there somewhere some kind of overview over the CLI switches and their usage?

[phate89]

Is there somewhere some kind of overview over the CLI switches and their usage?

in the txt shipped with the exe there is a txt that explain every switch with some example... but for now -start trim and -endtrim works only if there are both (bug)

[amtm]

3) Changing from frames to ms causes the starting offset delay to decrease each time you switch
4) The starting offset delay isn't subtracted from the cut file End setting so the output audio is too long

So having started looking at these bugs I need clarification on #3 and #4. When I switch between frames and ms I get the same value every time I flip back and forth other than rounding errors introduced due to the conversion from ms to frames and back but after that the value stays the same after subsequent switching. For example 155 ms converted to frames at 29.97 yields 5 frames, because all frame values are rounded to the next whole frame, and then converted back to ms gives 166ms. I can store the previous value milliseconds or seconds before conversion to restore it back to the original value if that was the issue you meant. But I don't see an ever decreasing value.

#4 I'm not quite understanding. The behavior of my version acts just the same as say 1.2.1.2 when it comes to specifying an offset delay and an end cut value. Can you clarify what you mean with number 4? Like specific values you are inputting and what you are expecting the duration to be because all values I'm trying gives equivalent durations to the last version before mine.

Thanks.

[amtm]

I've created a new version that addresses all the bugs I can reproduced. Can be downloaded here (https://github.com/downloads/athomasm/delaycut/delaycut.exe) with mirror here (http://www.multiupload.com/CWYAT4NG9Y).

- Fixes CLI issues reported by phate.
- Fixes issue with offset delay not being repopulated when file is dragged/dropped again.
- Fixes issue where changing FPS value did not recalculate target info.
- Fixes issue where unchecking cut box did not recalculate target info.
- Fixed behavior where start cut value would be overriden while inputting into the end cut field. This no longer happens and validation that end cut is not less than start cut happens when execute button is pressed.

Let me know if you find any other issues, especially clarification with the issues listed above that I can't reproduce, and I'll finalize this version before working on the new feature requests.

[Selur]

in the txt shipped with the exe there is a txt that explain every switch with some example...
Thanks! I totally overlooked that,... never scrolled down ;)

[Stereodude]

So having started looking at these bugs I need clarification on #3 and #4. When I switch between frames and ms I get the same value every time I flip back and forth other than rounding errors introduced due to the conversion from ms to frames and back but after that the value stays the same after subsequent switching. For example 155 ms converted to frames at 29.97 yields 5 frames, because all frame values are rounded to the next whole frame, and then converted back to ms gives 166ms. I can store the previous value milliseconds or seconds before conversion to restore it back to the original value if that was the issue you meant. But I don't see an ever decreasing value.

#4 I'm not quite understanding. The behavior of my version acts just the same as say 1.2.1.2 when it comes to specifying an offset delay and an end cut value. Can you clarify what you mean with number 4? Like specific values you are inputting and what you are expecting the duration to be because all values I'm trying gives equivalent durations to the last version before mine.

Thanks.3) When I load a file with a "DELAY -407ms". I have it set to frames when I load it. It shows up with a -12 frame delay. I change to ms and it turns into 400ms. Change it back to frames and it turns to -11. Back to ms and it's -367. Back to frames it's -10, etc, etc, etc...

4) It's been a while, but my complaint is that for example if you have a 250ms start delay and you are cutting at 50000ms (end) you get a file that's 50272ms long. IMHO it should be 50016ms long. This is because you're dealing with synchronizing the audio to the video. In this example 250ms of audio is missing. The video is 50000ms long so you don't want a total 50250ms of audio, you want 50000ms.

[amtm]

3) When I load a file with a "DELAY -407ms". I have it set to frames when I load it. It shows up with a -12 frame delay. I change to ms and it turns into 400ms. Change it back to frames and it turns to -11. Back to ms and it's -367. Back to frames it's -10, etc, etc, etc...

Okay, with that I can see it happening. Thanks. With positive values it wasn't showing it.


4) It's been a while, but my complaint is that for example if you have a 250ms start delay and you are cutting at 50000ms (end) you get a file that's 50272ms long. IMHO it should be 50016ms long. This is because you're dealing with synchronizing the audio to the video. In this example 250ms of audio is missing. The video is 50000ms long so you don't want a total 50250ms of audio, you want 50000ms.

Okay, testing this it seems to be the way the code has always worked since 1.2.1.2 gives the same duration for those input values. It's a simple enough change so if no one has any issues about changing the longstanding behavior I'll do it. I just don't want to break existing behavior that people might rely on.

[amtm]

Oh, so after more research to get the behavior you want with regards to the cut/delay values you simply need to check the "original length" checkbox. No code changes are needed so I'm going to close that issue and I've already corrected the other issue and I'll swap out the previous testing version with a new one to make sure no new regressions have popped before doing a final release. Also, I didn't do this previously but I will start doing version tagging on checkins so that it's easier to rollback to a previous version in git starting with this version before I begin doing new feature requests.

[amtm]

New testing version [links removed. replaced below]. Right now just need to know if any new bugs pop up or any regressions. Thanks!

[Stereodude]

Thanks for the new version. I found two bugs (well, one is leftover that's still not fixed):

1) Reopening the same file still doesn't auto populate the delay start field.

2) If the Original Length box is checked in the Delay area the end field is not also auto populated when a file is opened. You have to uncheck and recheck the box.

There also seems to be a mistake in the math somewhere when working in frames instead of msec. In 3 of my 4 tests the start and end AC3 frame were off by one (length was correct) when compared to working in msec from my excel spreadsheet. I will investigate further and give you a specific example later.

[amtm]

Redownload from the links just to double check you have the latest version. I just retested and the reopening does repopulate as I just checked by clearing the start delay and reopening the same file. Unchecking the box does recalculate. The reason unchecking the "original length" check box appears to not recalculate is that it populates the end delay field as well. You have to clear the fields after you uncheck.

[Stereodude]

Redownload from the links just to double check you have the latest version. I just retested and the reopening does repopulate as I just checked by clearing the start delay and reopening the same file. Unchecking the box does recalculate. The reason unchecking the "original length" check box appears to not recalculate is that it populates the end delay field as well. You have to clear the fields after you uncheck.I had the latest, but I downloaded it again just to be sure.

I'm not imagining these things...

1) http://img855.imageshack.us/img855/4612/bugno1.th.png (http://img855.imageshack.us/img855/4612/bugno1.png)

2) http://img337.imageshack.us/img337/7400/bugno2.th.png (http://img337.imageshack.us/img337/7400/bugno2.png)

[amtm]

It's working just fine here both with drag/drop and reopening through the open file dialog. I'm doing the exact same steps. I open a file, clear delay, reopen and the start delay repopulates. *shrug* Now the end delay not being updated if original length is checked I do see that not updating right.

[amtm]

New version here (https://github.com/downloads/athomasm/delaycut/delaycut.exe), mirror here (http://www.multiupload.com/Y912DMYSK9), which fixes populating the end delay correctly when "original length" is checked.

[hlmasterchief93]

so how to build the lastest one for ubuntu from Source code ?

[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

[amtm]

Yes, the DTS issue is something we discussed before and something I'll be addressing. It will be after I finish a couple of other issues and after I commit what I also have fixed locally.

A missing one from old delaycut is drag and drop.


Huh? Drag and drop is supported in this version just like in the old. You can drag to either the input or output text fields and it'll use that to open the file.

[XMEN3]

Yes, the DTS issue is something we discussed before and something I'll be addressing. It will be after I finish a couple of other issues and after I commit what I also have fixed locally.



Huh? Drag and drop is supported in this version just like in the old. You can drag to either the input or output text fields and it'll use that to open the file.

text?
In the old version:
drag and drop the file into the window will load the file naming output automatically adding "_fixed" at the end of it and saving in the source path without selecting any text for input.
Why i should use a text as input when is easier open the source with browse button?
Drag and drop the source into the window is the faster method.
thanks

[Selur]

"input or output text fields" = the field for the input/output, text just because you see a text an not i.e. a picture that in the gui representing the input.
I agree: drag&drop works fine. (dragging a ac3/dts/.. file and dropping it on the input/output fields, fills the fields,..)
->XMEN4 try it before complaining,...

[XMEN3]

"input or output text fields" = the field for the input/output, text just because you see a text an not i.e. a picture that in the gui representing the input.
I agree: drag&drop works fine. (dragging a ac3/dts/.. file and dropping it on the input/output fields, fills the fields,..)
->XMEN4 try it before complaining,...
I've mistaken the meaning of text field.
Anyway...
It does not load any file draggin into the window with 1.4.3.3...that's why say that
It loads only if i center the input field perfectly...not the whole window

[Selur]

works fine with v1.4.3.2 though :)

[amtm]

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

I don't know if I answered this before, but yes it can assuming you have encoded the mp3 file with the protection bit set which the file you are having the fixcrc problem with does not have set. So ultimately fixcrc is not going to work with your file anyway since it has no CRC info in the header. I've got a fix at least for the programming stalling so it will actually finish, but unfortunately from what I can see nothing can be done to salvage your file since it's so broken. Even with my fix from getting the processing to finish you get no actual output since there is nothing in the file that can be recovered (even 1.2.1.2 if you hit abort when it stalls at 100% has produced a 0 size file as well) and even eac3to errors out in trying to convert it. Though the file plays just fine in MPC-HC so the decoder must be much more error resilient. So I will put it on the TODO list to see if this can be improved but for now the hanging is fixed at least.

Also, there was a bug in the detecting of whether to enable the CRC error options and this is fixed locally so even files that should have triggered that to be enabled, such as ac3 files, did not do so because of a weird logic bug in translating the code over. I've got pretty much everything fixed up for a next release locally I just need to get some last minute cleanup before pushing the next version out. :o

Phate, did you end up getting any info from your issue?

[Selur]

Thanks for fixing the main problem and it would be nice it delaycut cut also output some sort of 'error message' when used through the console if it encounters such a problem and outputs a 0 byte file.

Cu Selur

[amtm]

Thanks for fixing the main problem and it would be nice it delaycut cut also output some sort of 'error message' when used through the console if it encounters such a problem and outputs a 0 byte file.

Cu Selur

That's one of the cleanups that I'm still working on before pushing this out. I'm also adding a help switch so that the README isn't the only place to find info on the CLI switches. The silent fail or silent completion is something that definitely needs to be remedied. The big thing is just making sure that the output and error messages are well worded so that's taking a bit of refinement to get right. After that the last thing I need to get incorporated is the new behavior for how cut and delay values are done that was discussed a page or so back. Once that is done I'll push out the newest bug fix version and start working on those enhancements still listed on github.

[phate89]

No i still can't compile qt to run it in vs...if i try to just debug the exe with command line switches i don't know why it didn't run at all..btw i didn't had a lot of time to try..

[amtm]

Posted the wrong file the first time so I'm posting this again. If you were quick enough to grab it, download again before testing.

I'm still working on getting pushed the extra CLI output, the change to the delay/cutting behavior and a few other cleanups, but here, mirror here is an intermediate test version that has the rounding fixes, the hang fix for Selur's file, fixes the GUI so the CRC options will enable when they should. Let me know if you find any regressions, new bugs, etc. I promise to get the rest of the stuff finished soon.

[phate89]

Posted the wrong file the first time so I'm posting this again. If you were quick enough to grab it, download again before testing.

I'm still working on getting pushed the extra CLI output, the change to the delay/cutting behavior and a few other cleanups, but here (https://github.com/downloads/athomasm/delaycut/delaycut.exe), mirror here (http://www.multiupload.com/ZSXE2HFTN3) is an intermediate test version that has the rounding fixes, the hang fix for Selur's file, fixes the GUI so the CRC options will enable when they should. Let me know if you find any regressions, new bugs, etc. I promise to get the rest of the stuff finished soon.
I use a lot the tool to cut at the start OR at the end of the audio.. but to do that i always have to set manually the end of the file or use command line... can you make the program take the audio to the end if the end cut is 0 instead of prompting an error?

edit:
unother bug:
i run this command:
delaycut -startsplit 400000 audio.ac3
to an ac3 in a 41 min length video and the creation enter in a loop... i kill delaycut.exe when the output file reach the 10 gb size.. the same even if i add a -endsplit 500000.. did you change default to frames or secs?
Edit2:
seems that the command line is completely screwed up.. nothing works..i tried with -endsplit 500 and it considers it like seconds by default.. if i force seconds with -inputtype seconds -endsplit 500 is out of range so it goes in infinite loop and the size of the file keeps growing..

[amtm]

I use a lot the tool to cut at the start OR at the end of the audio.. but to do that i always have to set manually the end of the file or use command line... can you make the program take the audio to the end if the end cut is 0 instead of prompting an error?

I can.


edit:
unother bug:
i run this command:
delaycut -startsplit 400000 audio.ac3
to an ac3 in a 41 min length video and the creation enter in a loop... i kill delaycut.exe when the output file reach the 10 gb size.. the same even if i add a -endsplit 500000.. did you change default to frames or secs?

No, I didn't change anything. I ran that same first command and can't reproduce that. It finishes normally. Can you post the file that is triggering that? The 4 sample ac3 files I pulled down from mplayer's sample files don't trigger that.

[phate89]

seems that the command line is completely screwed up.. probably the conversion between unit measures is the problem...i tried with -endsplit 500 and it considers it like seconds by default ( it gives me a 8 min 20 secs file audio ignoring the -startsplit).. if i force seconds with -inputtype seconds -endsplit 500 is out of range so it goes in infinite loop and the size of the file keeps growing..
(probably the infinite loop happens if you gave out of range frame values)

[amtm]

I've finally triggered the cut not working right issue but no infinite loop as it will always finish. I'll look into it when I get home.

Edit: It's weird because certain values work but others don't.

[phate89]

I've finally triggered the cut not working right issue but no infinite loop as it will always finish. I'll look into it when I get home.

probably the infinite loop is when there's a file of 1 min and you ask to cut from 2 to 3 mins... it didn't find the original audio and it keeps creating it..
Btw from command line milliseconds are considered seconds... and seconds are considered something bigger.. if i do:
-inputtype milliseconds -endsplit 500 it creates me a 500 secs file, if i set -inputtype seconds -endsplit 500 it creates a 5000 seconds file...
this is the reason of the loop.. it pass values bigger than it should.. so sometimes this value goes over the end of the file.. and when it does it starts looping

[amtm]

Remembering now, I have other CLI fixes still only locally committed because I know I was testing the CLI and it was working fine because I was testing this exact issue with only startsplit being specified. I'll get those pushed to github and rebuild tonight.

[amtm]

So the error wasn't actually CLI related. It was a logic error introduced in calculating the target info. I've fixed it locally and will push to github and post a new testing version momentarily.

[amtm]

New version here (https://github.com/downloads/athomasm/delaycut/delaycut.exe) and mirrored here (http://www.multiupload.com/PYZZNPBEKP). Fixes some the issue mentioned by phate due to some logic errors, has some additional CLI fixes and changes the behavior of the cut/delay text fields so that they will only repopulate with a 0 when empty when focus is lost so that it won't insert a 0 if you are trying to clear the field to type in a new value which was annoying. If there are no more issues to report I will get the rest of the CLI output finished and implement the new cut/delay behavior and I'll push out the full release.

[phate89]

New version here (https://github.com/downloads/athomasm/delaycut/delaycut.exe) and mirrored here (http://www.multiupload.com/PYZZNPBEKP). Fixes some the issue mentioned by phate due to some logic errors, has some additional CLI fixes and changes the behavior of the cut/delay text fields so that they will only repopulate with a 0 when empty when focus is lost so that it won't insert a 0 if you are trying to clear the field to type in a new value which was annoying. If there are no more issues to report I will get the rest of the CLI output finished and implement the new cut/delay behavior and I'll push out the full release.
Tried...the timing and the single switch problem are fixed...great!
But i think you have to add a check to avoid the loop if i enter an -endsplit bigger than the length of the track... if it is bigger you should prompt an error or simply copy the file...
It's very annoying to have to kill the process to stop it and someone can't realize why they have suddenly the hard disk full..

[amtm]

Argh, I meant to put that in and forgot. Fixing that now.

[amtm]

I've put in the check to cap the endsplit value to the duration if it's larger, yet testing on the previous version I can't get it to trigger it to write forever as you mention it does. It just stops when it reaches EOF when trying to read the file. The loop that happens when you process either runs until it hits the end frame value or when EOF happens, so the extra check I added should not be needed, which means your file is not properly triggering an EOF in the loop. Can you post the file you are using that can trigger it running forever?

[amtm]

Last test version before pushing a new bug fix release. Can be downloaded here and mirrored here. Let me know of any other issues.

[phate89]

I've put in the check to cap the endsplit value to the duration if it's larger, yet testing on the previous version I can't get it to trigger it to write forever as you mention it does. It just stops when it reaches EOF when trying to read the file. The loop that happens when you process either runs until it hits the end frame value or when EOF happens, so the extra check I added should not be needed, which means your file is not properly triggering an EOF in the loop. Can you post the file you are using that can trigger it running forever?
i understand now.. it's not a loop... it's the file that don't stop when it reach the end of the file.. so bigger it is the -endsplit and bigger the file is..
with the old bug the value i put was considered bigger than it should so it seems was an endless loop... because the end file was too big and i stop the file before..

i tried with a 41 m file.. if i do this command:
delaycut -endsplit 400000 audio.ac3
it takes 6 min 40 secs (right)
if i do
delaycut -endsplit 4000000 audio.ac3
it creates a file of 1 h and 6 minutes (the file is 41 mins so the rest is silence)

this with the new method of counting delays should be avoided i think..

[amtm]

That's definitely wrong since it should run equal length of time even with the larger endsplit. Can you open that file in the GUI and give it that larger split value then paste what it says for the target info? Like I said, if the endsplit value goes beyond the actual length of the file processing should stop when it hits EOF regardless of the change I did.

[phate89]

That's definitely wrong since it should run equal length of time even with the larger endsplit. Can you open that file in the GUI and give it that larger split value then paste what it says for the target info? Like I said, if the endsplit value goes beyond the actual length of the file processing should stop when it hits EOF regardless of the change I did.

====== INPUT FILE INFO ===============
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 120540672
Channels mode 3/2: L+C+R+SL+SR
Sampling Frec 48000
Low Frec Effects LFE: Present
Duration 00:41:51.264
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 78477
Bytes per Frame 1536.0000
Size % Frame size 0
CRC present: YES
======================================
====== TARGET FILE INFO ==============
Start Frame 0
End Frame 125000
Num of Frames 125001
Duration 01:06:40.032
NotFixedDelay 0.0000
======================================

[amtm]

Ahh, I found the problem. Fixing it.

[amtm]

Fixed. Once again can be grabbed here and mirrored here.

[phate89]

Fixed. Once again can be grabbed here (https://github.com/downloads/athomasm/delaycut/delaycut.exe) and mirrored here (http://www.multiupload.com/Y9QL30VIZF).

Tried.. the file it isn't bigger everytime but it still adds a frame..
if the original audio is 100 frames the program took from 0 to 100 frames.. increasing of 1 frame the size..

[amtm]

Slightly reworked it. Now it shouldn't round up a frame anymore. Download here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.4.zip) and mirrored here (http://www.multiupload.com/L1FQQ1AE4S).

[phate89]

Slightly reworked it. Now it shouldn't round up a frame anymore. Download here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.4.zip) and mirrored here (http://www.multiupload.com/L1FQQ1AE4S).

Seems that almost all bugs were fixed...

[amtm]

Seems that almost all bugs were fixed...

Well that's good. :D I have a bunch cleanup done to the code that I'm getting ready to push out in the next day or two so if there are any more bugfixes needed before that point, please let me know.

[phate89]

Well that's good. :D I have a bunch cleanup done to the code that I'm getting ready to push out in the next day or two so if there are any more bugfixes needed before that point, please let me know.

really looking forward to it :P

[amtm]

really looking forward to it :P

You shouldn't notice these changes unless something gets accidentally broken. :o But with these changes, I can now cleanly implement the new features.

[phate89]

You shouldn't notice these changes unless something gets accidentally broken. :o But with these changes, I can now cleanly implement the new features.

the first thing i look forward is the silent delay... so i can replace ea3c3to with this in my app making editing faster :D

[phate89]

One question.. I never used the frame method.. But we're talking about video frames right? For this reason you need fps.. In the future can you add an audio frame option to cut audio at the frame we want? I often use ac3 files with 2.0 and 5.1 content and i could need to cut at the exact frame

[amtm]

Yes, the frames method right now is for video frames. I can add an option to cut by audio frame as well.

[amtm]

Since no one has made light any new bugs I've updated the first page for the new version. Also, for anyone actually compiling this from source, starting with 1.4.3.4 I've started tagging releases to make it easier to pull down source for a known version. What this also means is that I will no longer guarantee that HEAD will compile whereas previously I would always make sure HEAD at least compiled, so that I can more rapidly push changes without worrying about someone trying to build it and it breaking. So if you want a version that will be known to compile, you will want to pick up the latest tagged version.

[amtm]

So apparently writing out to the CLI from a GUI app is not possible without creating two different versions of the app which I'm too lazy to do at least at this point. So instead any error messaging will be written to an error.log file instead when invoked from the CLI.

[Selur]

I did this some time ago so I'm no totally sure if I get it right from memory:

to your pro file add:
CONFIG += qt \
console
this will add console output to your gui, but add an additional console windows (under Windows only <- argh!)

so to stop this console window when you use the GUI you modify your main.cpp

1st add:
#ifdef Q_OS_WIN32
#include <windows.h>
#endif

and before starting the gui:
#ifdef Q_OS_WIN32
if (gui) {
FreeConsole(); //this will kill the console window; downside console window will be visible for a short time
}
#endif
gui could be set to true if for example there's no /nogui in argv.

Cu Selur

Ps.: hiding the gui is probably no problem :) (btw.: I haven't figured out how to output to the console under Windows form a qt GUI)

[amtm]

Interesting workaround. I've seen the Config+=console thing but everything I saw (though it was a bit dated) said that then you would only get a console window. I'll definitely try that out.

Edit: That worked perfectly. Thanks.

[amtm]

So a question about a change to the CLI usage. I'm thinking of just removing the "-console" switch and just having it always output to the CLI when you use delaycut that way. Does anyone care? This will impact another change I want to make. Currently if you only supply 2 commandline arguments to the executable based on previous behavior, it will launch the GUI and use that second argument as the input file name. One major bug about this with the older versions is that you happened to just do "delaycut -console" it would think "-console" was a filepath and would only actually execute via CLI at least 3 arguments were passed. Does anyone care if I just always treat the launching of the app through the commandline as wanting to only use it via CLI? To put it another way, does anyone actually launch the program from cmd.exe and passes in the filename as an argument instead of just drag/drop or using the browse buttons to open a file?

[Selur]

Does anyone care if I just always treat the launching of the app through the commandline as wanting to only use it via CLI? To put it another way, does anyone actually launch the program from cmd.exe and passes in the filename as an argument instead of just drag/drop or using the browse buttons to open a file?
no :)

[phate89]

So a question about a change to the CLI usage. I'm thinking of just removing the "-console" switch and just having it always output to the CLI when you use delaycut that way. Does anyone care? This will impact another change I want to make. Currently if you only supply 2 commandline arguments to the executable based on previous behavior, it will launch the GUI and use that second argument as the input file name. One major bug about this with the older versions is that you happened to just do "delaycut -console" it would think "-console" was a filepath and would only actually execute via CLI at least 3 arguments were passed. Does anyone care if I just always treat the launching of the app through the commandline as wanting to only use it via CLI? To put it another way, does anyone actually launch the program from cmd.exe and passes in the filename as an argument instead of just drag/drop or using the browse buttons to open a file?
No.. and i also will sort the order of the switches.. actually only work if i put it before the paths...i think it's more logical to put as first the input file.. then the switches

[amtm]

For me it makes more sense to do it the other way of delaycut <options> -o <output> <input> like a lot of Unix CLI tools.

[Selur]

or don't care about the order and give <input> an '-i' -> parsing should be easy,... if it starts with an '-' it's an option if the following parameter (if there is one) also has an '-' it a unary option otherwise the next one is the parameter to the option before,..

[amtm]

What I'll do is make it so that if you supply a -i switch you can specify the input file anywhere you want. In the absence of that switch it will implicitly assume the input file is specified as the last argument and fail if that isn't a valid file name. That way if you want you can do both delaycut <input> <options> or delaycut <options> <input>.

[phate89]

For me it makes more sense to do it the other way of delaycut <options> -o <output> <input> like a lot of Unix CLI tools.

maybe it's because i'm used to windows.. the only cli tool i use that puts the input file after is lame...
Trying the tool to find bugs i see that is annoying if i have to correct the parameter everytime to find the good one go to the middle (between the path of the executable and the path of the audio)..

but an -i option could be good as well..

[amtm]

New version that adds back in CLI messages of progress and errors. I've also removed the "-console" parameter and have renamed a few of the other parameters. The README is updated to show the new parameters. Can be downloaded here (taken down temporarily).

[Selur]

Could you add something like a '-version' that shows the version info? (would help to adjust scripts&co when using the CL version and the switches changed)

Cu Selur

[amtm]

Removing cause there's an issue I missed.

[amtm]

Yeah, that's possible. I've updated the code online to provide that. I'll rebuild and repost the binary when I get home.

[Selur]

Nice :)

[Sparktank]

Oooh, the first page is looking really nice with updates and info :)

[phate89]

in the list of switches the -same is missing ;)

[amtm]

in the list of switches the -same is missing ;)

Yeah it's always been missing and I meant to fix that in the readme. Will do that now.

Be home in about 90 minutes and I'll post the new binary. :) Assuming no regressions or new bugs it means I will start with the additional changes and new features.

[amtm]

Got home late. Here (https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.5.7z) is the new version.

[Selur]

https://github.com/downloads/athomasm/delaycut/delaycut1.4.3.5.7z -> gives me a 404

[amtm]

Really? Argh, github. Sorry about that, link should be fixed now.

[Selur]

works now, thanks!

another thing that changed, before I called:
delaycut -fixcrc fix -o "D:\Encoding Temp\Test-AC3-5.1__aid_1__09_09_18_151_02.ac3" -i "D:\Encoding Temp\Test-AC3-5.1__aid_1__09_09_18_151_01.ac3"
and ended up with a file named: "D:\Encoding Temp\Test-AC3-5.1__aid_1__09_09_18_151_02_fixed.ac3"
now the output name is: "D:\Encoding Temp\Test-AC3-5.1__aid_1__09_09_18_151_02.ac3"
is this intended? (no problem if so, I even prefer this)

Cu Selur

[amtm]

Yes, that is the way it is intended since that makes more sense to me. What you specify via -o is what the output file name is. Like before, though, if you don't specify -o it'll just do the appended _fixed to the end.

[Selur]

Okay, thanks for the info. :)

[amtm]

You're welcome. Let me know if you find any issues. :)

[Selur]

Sure, but up-to-now everything I used seems to work like intended. :)

[amtm]

Just to give some hints, along a few of the new features and some feature changes, I'm also looking into a few efficiency optimizations (though it is fairly fast as is). Things like not reading and writing a single frame at a time, which is a terrible way to do IO, and instead reading in a block of audio frames into memory before processing. Also trying out the QtConcurrent::map() (http://developer.qt.nokia.com/doc/qt-4.8/qtconcurrentmap.html#map-2) function to see if any improvements come with processing those block of frames in parallel before writing back out so if you have a multi-core setup you should get some speed improvement. I'm not sure if this will provide a huge benefit unless you are processing rather large audio files but it's something I'm going to play around with since QtConcurrent looks like an interesting framework.

[phate89]

Just to give some hints, along a few of the new features and some feature changes, I'm also looking into a few efficiency optimizations (though it is fairly fast as is). Things like not reading and writing a single frame at a time, which is a terrible way to do IO, and instead reading in a block of audio frames into memory before processing. Also trying out the QtConcurrent::map() (http://developer.qt.nokia.com/doc/qt-4.8/qtconcurrentmap.html#map-2) function to see if any improvements come with processing those block of frames in parallel before writing back out so if you have a multi-core setup you should get some speed improvement. I'm not sure if this will provide a huge benefit unless you are processing rather large audio files but it's something I'm going to play around with since QtConcurrent looks like an interesting framework.
a short summary.. so you change or you already changed how the app handles delays, how handles cuts, how handles i/o, how handles gui, how some feature works...
Practically you're going to do an almost complete rewrite :D

[amtm]

Well there will still be a lot of the original code left especially for the audio processing. Though with the cleanups and refactoring it will look a lot different and hopefully a lot clearer to follow as I will try to comment it more for areas that, at least for me, were confusing upon first looking at it. Also, I will replace a lot of the magic hex numbers littered throughout the code with constants to make those easier to figure what they are for.

BTW, I tagged the latest release so for anyone compiling from source will want to use that. There was a fix for building on non-Windows platforms that I slipped in as well for a bug that would cause a compile error.

[phate89]

Well there will still be a lot of the original code left especially for the audio processing. Though with the cleanups and refactoring it will look a lot different and hopefully a lot clearer to follow as I will try to comment it more for areas that, at least for me, were confusing upon first looking at it. Also, I will replace a lot of the magic hex numbers littered throughout the code with constants to make those easier to figure what they are for.

BTW, I tagged the latest release so for anyone compiling from source will want to use that. There was a fix for building on non-Windows platforms that I slipped in as well for a bug that would cause a compile error.
Thanks for commenting it.. maybe when you will finish the reorganization i will look at it and try again to understand how it works

[amtm]

For anyone who wants to play with it, here is a test version that supports using audio frames as input type. Valid values when specifying inputtype via CLI are now "milliseconds", "seconds", "audioframes" and "videoframes". There are also a few tweaks and bugfixes in this, too (for example end delay value wasn't being applied properly *doh*).

[amtm]

New test version here (https://github.com/downloads/athomasm/delaycut/delaycut-test.7z) with some fixes.

Edit: Updated once more for a CLI fix for the audioframes input type to check startcut and endcut lengths.

[phate89]

i just tried the latests versions but they still have the old -start -end -startsplit -endsplit... the new switches doesn't work... btw when i use -info it crashes to me..

[amtm]

I forgot the change the parameter checking code. :o Can you post the file that crashes? I've tried the -info switch with a random assortment of samples hosted by mplayer and got no crashes.

[phate89]

I forgot the change the parameter checking code. :o Can you post the file that crashes? I've tried the -info switch with a random assortment of samples hosted by mplayer and got no crashes.

no i confused -info with a sort of help switch that output all the switches (that could be an useful switch).. so i don't pass any input file.. that's the reason of the crash

[amtm]

Yeah, -info has always been to just have it dump the info about the file. I'll look into why it crashes though.

Edit: I see the problem. Pushed the fix. Will post a new build tonight.

Additional edit: I'll put in a -help switch as well. Forgot to do that.

[phate89]

Yeah, -info has always been to just have it dump the info about the file. I'll look into why it crashes though.

Edit: I see the problem. Pushed the fix. Will post a new build tonight.

yes i never used it... but maybe an -help that prompts all the switches without do anything and without the need of opening the readme file could be useful now that i think of...

[amtm]

Yeah, I'll put one in. It was meant to be put in but it was just overlooked.

[amtm]

Ok. This (https://github.com/downloads/athomasm/delaycut/delaycut-test.7z) now has all the fixes and implements the -help switch.

[Selur]

as a side note: remember to update the version info from time to time ;)

[amtm]

I will when I push out the real release.

[Selur]

okay :)

[amtm]

New version here (http://www.videohelp.com/tools?d=delaycut1.4.3.6.7z). Fixes CLI argument parsing, adds audio frame cut/delay support, adds -help switch and a few additional bug fixes.

[Thunderbolt8]

might be in here somewhere but cant find it atm, so I have to ask: is DTS-HD MA also supported or only normal DTS files? (if so, would it be possible to add filetype recognition for .dtsma .dtshr .dtshd, those are the most common ones when using eac3to, so you dont have to rename the file in order to load it with delaycut).

from what it seems, duration time is quite off when loading such a file (maybe also when being multichannel at the same time?)

v .7 also still has 1.4.3.6 in the title and as unzip path btw.

[amtm]

DTS-HD MA is still not supported yet. It is coming though. Also, the version number is correctly 1.4.3.6. Are you confusing the .7z from the archive extension?

[Selur]

DTS-HD MA is still not supported yet. It is coming though.
Nice! (after that trueHD would be cool :))

[Thunderbolt8]

DTS-HD MA is still not supported yet. It is coming though. Also, the version number is correctly 1.4.3.6. Are you confusing the .7z from the archive extension?maybe, oops

[kypec]

New version here (http://www.videohelp.com/tools?d=delaycut1.4.3.6.7z). Fixes CLI argument parsing, adds audio frame cut/delay support, adds -help switch and a few additional bug fixes.

Well, I really don't know what I'm doing wrong but this version 1.4.3.6 is giving me nothing but error messages:
delaycut -inputtype seconds -startcut 0 -cutend 6318.648 -i test.ac3
No valid input type specified.

delaycut -startcut 0 -cutEnd 6318648 -i test.ac3
Unrecognized switch: -cutend.

delaycut -startcut 0 -endsplit 6318648 -i test.ac3
Unrecognized switch: -endsplit.

Here is info on my test AC3 file (demuxed directly from DVD "Anne of Green Gables - Sequel" DISC SIDE A)
General
Complete name : D:\Source\test\test.ac3
Format : AC-3
Format/Info : Audio Coding 3
File size : 145 MiB
Duration : 1h 45mn
Overall bit rate mode : Constant
Overall bit rate : 192 Kbps

Audio
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Duration : 1h 45mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 145 MiB (100%)

Luckily GUI did work though it exhibits some funky behaviour when you check/uncheck Cut checkbox with already inserted value in seconds --> target info values seem to be recalculated as if the input type was still milliseconds. It's only a cosmetic bug AFAIK, once you click PROCESS the output file is correctly generated despite the info showing too short duration.

[amtm]

Well, I really don't know what I'm doing wrong but this version 1.4.3.6 is giving me nothing but error messages:
delaycut -inputtype seconds -startcut 0 -cutend 6318.648 -i test.ac3
No valid input type specified.

I see the bug. It's a logic problem in checking the valid types.

delaycut -startcut 0 -cutEnd 6318648 -i test.ac3
Unrecognized switch: -cutend.

It's endcut not cutEnd. Seems I forgot to update the README for that one switch.

delaycut -startcut 0 -endsplit 6318648 -i test.ac3
Unrecognized switch: -endsplit.

endsplit is not a valid switch. It's endcut.

Here is info on my test AC3 file (demuxed directly from DVD "Anne of Green Gables - Sequel" DISC SIDE A)
General
Complete name : D:\Source\test\test.ac3
Format : AC-3
Format/Info : Audio Coding 3
File size : 145 MiB
Duration : 1h 45mn
Overall bit rate mode : Constant
Overall bit rate : 192 Kbps

Audio
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Duration : 1h 45mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 145 MiB (100%)

Luckily GUI did work though it exhibits some funky behaviour when you check/uncheck Cut checkbox with already inserted value in seconds --> target info values seem to be recalculated as if the input type was still milliseconds. It's only a cosmetic bug AFAIK, once you click PROCESS the output file is correctly generated despite the info showing too short duration.

I'm not following what you mean. What does the target info say and what do you expect it to say? When I set input type to seconds and input seconds in the cut field when I check and uncheck it is calculating it exactly right. And yes, internally it is translating your values into milliseconds when calculating the target info, but that should in no way cause durations to look different.

I've updated the CLI info on the main page since I had missed a few switches to rename.

[amtm]

New version here (http://www.videohelp.com/download/delaycut1.4.3.7.7z). Fixed the logic bug, updated the README and the output of -help to the properly named switches.

[kypec]

New version here (http://www.videohelp.com/download/delaycut1.4.3.7.7z). Fixed the logic bug, updated the README and the output of -help to the properly named switches.
:thanks: a lot but...

you forgot to update -version number in CLI, it still shows 1.4.3.6
you forgot to update README section where CLI switches are explained (not Examples), there's still -cutEnd mentioned
funky behaviour with check/uncheck toggling that I've been experiencing yesterday is now gone, strange...:confused:

Anyway, your prompt support and bug fixing is outstanding, much appreciated!

[amtm]

Yeah missed those two. I did manage to fix it on the front page of this thread, in output of the -help switch, and even in the examples themselves yet missed it in one place in the README. Argh... I've fixed them both and I now set the version string in one place in the code so there should be no more issues with them being out of sync. I've got most of the new cutting and delaying behavior implemented (along with cutting within the file and inserting silence within the file) and will try to get in a fix for inserting silence for DTS core tracks extracted from DTS-HD MA tracks in the next release in a day or so.

And just so everyone knows the new cut/delay behavior works as follows:

If a delay is set in the filename, set from something like DGIndex, etc, and the delay is positive it will be set in the delay field and this will insert silence. If it's negative it will be treated as a cut value, since that's really what negative delay is doing, and will be added to the start cut and the cut checkbox will be checked. If both cut values and delay, I'm actually thinking of renaming it to "insert silence" since that's what it will really be doing from now on, values are specified the cutting will be done first and then the silence frames will be added at the specified points. That is unless silence will be added within the file and that will be done before cutting so that there is less chance for error prone translation to the position within the newly cut file.

Anyone have any issues or object with this new behavior?

[Selur]

If a delay is set in the filename, set from something like DGIndex, etc,...
Is this only for the GUI or also for the command line? (I prefer to set delay&co manually there)
+ What will happen if I call '-startdelay' with a negative value?

[amtm]

Is this only for the GUI or also for the command line? (I prefer to set delay&co manually there

The GUI will pull it out automatically and the CLI will read it if you specify the "-auto" switch.

+ What will happen if I call '-startdelay' with a negative value?

For the CLI it'll maintain the current behavior. It'll offset your startcut value or if no startcut value is specified it'll end up being your startcut value.

For the GUI, it'll be populated as a cut value. I'm also going to change the GUI so that negative delay isn't accepted. If you want a negative delay, just modify your start cut value in the GUI since that's what it was doing behind the scenes, anyway.

[Selur]

Thanks for clearing that up! :) (-> so, no objections from my side :))

[amtm]

Thanks for clearing that up! :) (-> so, no objections from my side :))

Okay. Maintaining the behavior for the CLI is good so for automated tools like yours that you don't get any added complexity. If you always just specify "-auto" it'll do the work for you so you don't have to specify the -startdelay and it'll work the exact same as if you had (obviously barring any bugs ;)).

[phate89]

And just so everyone knows the new cut/delay behavior works as follows:

If a delay is set in the filename, set from something like DGIndex, etc, and the delay is positive it will be set in the delay field and this will insert silence. If it's negative it will be treated as a cut value, since that's really what negative delay is doing, and will be added to the start cut and the cut checkbox will be checked. If both cut values and delay, I'm actually thinking of renaming it to "insert silence" since that's what it will really be doing from now on, values are specified the cutting will be done first and then the silence frames will be added at the specified points. That is unless silence will be added within the file and that will be done before cutting so that there is less chance for error prone translation to the position within the newly cut file.

Anyone have any issues or object with this new behavior?

I think it's confusing for people that only use the tool to apply delay..they want to apply delay and they search for it...
naturally you're right.. a negative delay it's only a cut at the start... but also the positive delay it's an insert of silence at the start... so why remove only the negative?
In my case i have a lot of times both cut and a negative delay... it's a lot easier insert both values without to have to calc it manually...

[Selur]

@amtm: assuming you are the maintainer of http://download.opensuse.org/repositories/home:/amtm/xUbuntu_10.04/ could you update is to a more current version ? thanks.

[pandv2]

Hello,

Had you thinked about the command line switchs to allow multiple adds and cuts in the middle of stream? (I think you want to implement this). I am doing something similar for subtitles and because the use is paralel (cut in audio, cut in subs...) maybe I can clone the sintax to simplify the use.

Thanks.

[pandv2]

Hello,

I thinked delaycut supported mp2 and mp3 files, but maybe I am wrong because this formats are not in the list of available formats (and I can not open them).

But I think in older versions I used delaycut to fix mp3 files. If delaycut doesn't suport this files, is there any program to do with mp3 what delaycut does with ac3?

Thanks.

[Midzuki]

Hello,

I thinked delaycut supported mp2 and mp3 files, but maybe I am wrong because this formats are not in the list of available formats (and I can not open them).

Try renaming your .MP2s and .MP3s to .MPA ?????

[pandv2]

Try renaming your .MP2s and .MP3s to .MPA ?????

Of course it works. And also if I use the command line version or select all files (*.*). It's only a cosmetic bug, but a bug. I only report it because amtm is developing (I hope) it.

[amtm]

Sorry, I've been away for a while due to a variety of reasons, but I'm still working on it but it probably won't be for another 2 weeks before getting a new version due to some travelling I've got to do.

Yes, it supports mp3. I'll change the open file filters as I just copied the way the original program did it which only did *.mpa and you had to do "all files" to get the mp3. It's nothing but a carry over that can be changed.

[Selur]

delaycut -fixcrc fix -inputtype milliseconds -startdelay -1190 -o "D:\Encoding Output\fixDelay_ger_aid_6122__13_26_48_111_06.ac3" -i "D:\Encoding Output\fixDelay DELAY -1190ms_ger_aid_6122__13_26_48_111_05.ac3"
triggers an unwanted 'milliseconds' Popup-Window, would be nice if this would NOT happen when called through the command line (better output something to std::cerr or std::out)

+ delayac3.cpp misses:
#include "math.h"

+ some thing it wrong with delaycut.pro, using:
QT += core gui
CONFIG += qt \
console

TARGET = delaycut

!win32 {
target.path = /usr/bin
INSTALLS += target
}

TEMPLATE = app

SOURCES += main.cpp\
delaycut.cpp \
delayac3.cpp \
dragdroplineedit.cpp

HEADERS += delaycut.h \
sil48.h \
delayac3.h \
types.h \
dragdroplineedit.h

FORMS += \
delaycut.ui

RESOURCES += \
delaycut.qrc

RC_FILE = delaycut.rc
works fine on Linux&Mac

Cu Selur

[hlmasterchief93]

sorry, but how to compile delaycut in ubuntu ?
i check the README but i cant see the instruction
i use

git clone git://github.com/athomasm/delaycut.git
cd delaycut
qmake
make

and it's returned error


g++ -m64 -Wl,-O1 -o delaycut -L/usr/lib/x86_64-linux-gnu -lQtGui -lQtCore -lpthread
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [delaycut] Error 1

[Selur]

Did you try the changes I posted above? (adjusting delaycut3.cpp and delaycut.pro)
Compiling works fine for me with these changes (on ubuntu 32/64 and mac osx x)

[Snakekick]

@Selur
sorry for my question but how do i make this changes?
i did not have the file delaycut3.cpp
qmake give not response and make give me the same error @hlmasterchief93

**Edit***

delaycut3.cpp== delayac3.cpp

[Selur]

i did not have the file delaycut3.cpp and delaycut.pro
That is strange since, qmake generates the MakeFiles by looking into the delaycut.pro file and they are both listed over at: https://github.com/athomasm/delaycut
I see I made a typo delaycut3.cpp should be delayac3.cpp ;)

[Overdrive80]

Hi guys, I want remove a segment of ac3 file. I put a example:

First part: 0ms-5000ms
Secong part: 6000ms-end

Of this way, I would remove 999ms intermediate. ¿How I should configure delaycut for it?

[Sparktank]

Hi guys, I want remove a segment of ac3 file. I put a example:

First part: 0ms-5000ms
Secong part: 6000ms-end

Of this way, I would remove 999ms intermediate. ¿How I should configure delaycut for it?

MKVtoolnix has a function (newly implemented) to trim given specific time lengths.
Which is perfect for trimming the beginning and/or the end of a compliant Matroska file.
Mux the AC3 into an MKA (Matroska Audio) using mmg (http://www.videohelp.com/tools/mkvtoolnix) and apply the splits you want.

Documentation on the -split function here.
http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split

You can later demux the AC3 using MKVtoolnix (http://www.videohelp.com/tools/mkvtoolnix) with MKVExtractGUI (http://www.videohelp.com/tools/MKVExtractGUI-2) or other tool.

[tebasuna51]

@Sparktank

The easy way is use, like a say to Overdrive80 in other post, eac3to:

eac3to input.ac3 output.ac3 -edit=0:00:05.000,-1000ms

(remove 992ms without recode)

With DelayCut we can Cut first part 0 to 5000ms, obtain the second part with a -6000ms Delay and after join the 2 parts.

[mariner]

@Sparktank

The easy way is use, like a say to Overdrive80 in other post, eac3to:

eac3to input.ac3 output.ac3 -edit=0:00:05.000,-1000ms

(remove 992ms without recode)

With DelayCut we can Cut first part 0 to 5000ms, obtain the second part with a -6000ms Delay and after join the 2 parts.

Greetings tebasuna51.

How about inserting silence? Would a + sign work for both cases?
Can multiple edits be performed by a single command line?

Many thanks and best regards.

[tebasuna51]

To insert 1000ms of silence:

eac3to input.ac3 output.ac3 -edit=0:00:05.000,1000ms -silence

(with values less than 1000ms the default for eac3to is loop the previous frames)

[mariner]

Many thanks, tebasuna51.

1. eac3to doesn't like -edit=0:00:00.000,12750ms -silence. Minimum start time accepted is 13s. What could be wrong? It's a 6-channel 448kbps AC3 stream.

2. One command for each edit point?

[tebasuna51]

If you want a initial delay is enough:

eac3to input.ac3 output.ac3 +12750ms

[mariner]

@Sparktank

The easy way is use, like a say to Overdrive80 in other post, eac3to:

eac3to input.ac3 output.ac3 -edit=0:00:05.000,-1000ms

(remove 992ms without recode)

With DelayCut we can Cut first part 0 to 5000ms, obtain the second part with a -6000ms Delay and after join the 2 parts.

To insert 1000ms of silence:

eac3to input.ac3 output.ac3 -edit=0:00:05.000,1000ms -silence

(with values less than 1000ms the default for eac3to is loop the previous frames)

If you want a initial delay is enough:

eac3to input.ac3 output.ac3 +12750ms

Many thanks for these excellent beginner's guides.

Would you be kind enough to also look at a related problem posted here?

http://forum.doom9.org/showthread.php?p=1615955#post1615955

Best regards.

[tebasuna51]

Would you be kind enough to also look at a related problem posted here?

http://forum.doom9.org/showthread.php?p=1615955#post1615955

Seems a tsMuxeR problem not related with Delaycut or eac3to.

But you can use Delaycut or eac3to to avoid the problem.
When you add a delay here to a ac3 track, silent phisycal frames are added to the ac3 and you don't need add timeshift in audio/video containers.

If you need a delay >4935ms for a ac3 track in m2ts container, first use:

eac3to track.ac3 new_track.ac3 +4960ms

and you can now add the new_track to tsMuxeR without timeshift.

[mariner]

You're right. Will post reply at tsMuxeR thread.

Once again, many thanks and best regards.

[djmasturbeat]

delaycut v1.4.3.7 hangs on "crc errors - silence" mode for some files
it just makes zero progress
fixed file remains at zero kb even after an hour
also delaycut becomes unresponsive and won't respond to abort
(but it will close out with the X at upper rt)

esaxple log :
[Input info]
Bitrate=448
Actual rate=448
Sampling Frec=48000
TotalFrames=193208
Bytesperframe=1792.0000
Filesize=346228957
FrameDuration= 32.0000
Framespersecond= 31.2500
Duration=01:43:02.659
Channels mode=3/2: L+C+R+SL+SR
LFE=LFE: Present
[Target info]
StartFrame=0
EndFrame=193207
NotFixedDelay= 0.0000
Duration=01:43:02.624

1.3.0.0 performs quickly on same files, a matter of seconds.

if you need a sample please feel free to pm me.

[GCRaistlin]

Is delaycut still being developed? There's some bugs there, has it any sense to report them here?

[Selur]

no clue, but even if it's not developed any more atm. development might start again, so reporting to the bug tracker always is a good idea.

[GCRaistlin]

Selur, you mean reporting here, or there's a special bugtracker for delaycut?

[Selur]

Best report to the bug tracker on the project home page: https://github.com/athomasm/delaycut/issues

[XMEN3]

Hi, i know that eac3to fixes delay in both dts and dtshd tracks when extracting, is possible implement this frame fix on this software?

[Sparktank]

https://github.com/athomasm/delaycut/issues

I get 404 on that.
Even if I reduce to just athomasm, it's 404.

Someone mirrored it here:
https://github.com/darealshinji/delaycut

[tebasuna51]

I get 404 on that.
Even if I reduce to just athomasm, it's 404.

Someone mirrored it here:
https://github.com/darealshinji/delaycut

Where there are a new v1.4.3.8, but seems buggy.

Only loading a test ac3 file we can see differences between DelayCut versions:

= INPUT FILE INFO =================
v1.3.0 CORRECT v1.4.3.7 v1.4.3.8
---------------- ---------------- ------------------
File is ac3 ac3 ac3
Bitrate (kbit/s) 192 192 448 (?)
Act rate (kbit/s) 192.000 192.000 448.000 (?)
File size (bytes) 480000 480000 480000
Channels mode 2/0: L+R 2/0: L+R 2/2: L+R+SL+SR (?)
Sampling Frec 48000 48000 48000
Low Frec Effects LFE: Not present LFE: Not present LFE: Present (?)
Duration 00:00:20.000 00:00:20.000 00:00:08.571 (?)
Frame length (ms) 32.000000 32.000000 32.000000
Frames/second 31.250000 31.250000 31.250000
Num of frames 625 625 267 (?)
Bytes per Frame 768.0000 768.0000 1792.0000 (?)
Size % Framesize 0 0 201 (?)
CRC present: YES YES YES
= TARGET FILE INFO ================ ============= ==============
Start Frame 0 0 0
End Frame 624 624 266 (?)
Num of Frames 625 625 267 (?)
Duration 00:00:20.000 00:00:19.968 (?) 00:00:08.512 (?)

v1.4.3.7 is buggy because do a wrong calculation of target file duration.
Then always than I want a cut output one more frame than needed, if I want 3200 ms (100 frames) output 101 frames (3032 ms).

But v1.4.3.8 detect wrong Bitrate, Channels, LFE, etc. (reported here (https://github.com/darealshinji/delaycut/issues/4))

EDIT:
After some changes here is a build than work better than v1.4.3.7: delaycut_testbuild (https://github.com/darealshinji/delaycut/files/602290/delaycut_testbuild.zip)

[tebasuna51]

New release v1.4.3.9 here https://github.com/darealshinji/delaycut/releases

[manolito]

@tebasuna

Too bad but for v1.4.3.9 there is no qt4 build which means that it won't run under my WinXP...

Question:
In this post:
https://forum.doom9.org/showthread.php?p=1797824#post1797824
there is a link to a beta version which also contains a qt4 build. This build runs fine, so I'd like to know if the bugs from v1.4.3.8 are fixed in this beta version?


Thanks and Cheers
manolito

[tebasuna51]

... This build runs fine, so I'd like to know if the bugs from v1.4.3.8 are fixed in this beta version?
I'm not tested all the options but seems OK for me.

[manolito]

:thanks: