View Full Version : delaycut - ac3/eac3/dts/mpa/wav delay+cut tool: v1.4.3.7
amtm
8th January 2012, 22:59
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
9th January 2012, 11:55
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
9th January 2012, 12:00
"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
9th January 2012, 12:23
"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
9th January 2012, 12:27
works fine with v1.4.3.2 though :)
amtm
11th January 2012, 15:18
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
11th January 2012, 16:54
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
11th January 2012, 17:02
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
11th January 2012, 17:21
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
12th January 2012, 15:41
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
12th January 2012, 16:03
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
12th January 2012, 16:35
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
12th January 2012, 16:43
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
12th January 2012, 16:43
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
12th January 2012, 16:50
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
12th January 2012, 16:51
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
13th January 2012, 01:16
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
13th January 2012, 02:11
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
13th January 2012, 11:27
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
13th January 2012, 15:16
Argh, I meant to put that in and forgot. Fixing that now.
amtm
13th January 2012, 15:36
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
13th January 2012, 15:48
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
14th January 2012, 23:43
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
14th January 2012, 23:46
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
14th January 2012, 23:53
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
15th January 2012, 01:36
Ahh, I found the problem. Fixing it.
amtm
15th January 2012, 06:02
Fixed. Once again can be grabbed here and mirrored here.
phate89
15th January 2012, 11:39
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
15th January 2012, 18:09
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
16th January 2012, 10:18
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
16th January 2012, 15:57
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
16th January 2012, 18:55
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
16th January 2012, 20:52
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
17th January 2012, 00:04
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
17th January 2012, 13:30
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
17th January 2012, 15:15
Yes, the frames method right now is for video frames. I can add an option to cut by audio frame as well.
amtm
17th January 2012, 18:48
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
21st January 2012, 00:44
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
21st January 2012, 01:31
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
21st January 2012, 02:50
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
23rd January 2012, 23:46
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
23rd January 2012, 23:51
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
24th January 2012, 01:45
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
24th January 2012, 03:36
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
24th January 2012, 08:18
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
24th January 2012, 16:31
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
25th January 2012, 00:06
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
25th January 2012, 15:45
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
25th January 2012, 16:01
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
25th January 2012, 16:01
Removing cause there's an issue I missed.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.