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

Originally Posted by phate89

Seems that almost all bugs were fixed...

Well that's good. 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]

Originally Posted by amtm

Well that's good. 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

Originally Posted by phate89

really looking forward to it :P

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

[phate89]

Originally Posted by amtm

You shouldn't notice these changes unless something gets accidentally broken. 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

[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

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

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.

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)

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.

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]

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

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

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

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]

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

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

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

Removing cause there's an issue I missed.