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

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