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

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

Originally Posted by phate89

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.

Got home late. Here is the new version.

[Selur]

https://github.com/downloads/athomas...ycut1.4.3.5.7z -> gives me a 404

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

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.

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.

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() 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]

Originally Posted by 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() 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

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]

Originally Posted by 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.

Thanks for commenting it.. maybe when you will finish the reorganization i will look at it and try again to understand how it works

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

New test version here 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..