Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th December 2011, 22:40   #101  |  Link
amtm
Guest
 
Posts: n/a
Download the source. Make sure you have all the dev packages needed for compiling C++ and that you have qt4-qmake then run.

Quote:
qmake -makefile delaycut.pro CONFIG+=Linux
make
  Reply With Quote
Old 28th December 2011, 15:41   #102  |  Link
amtm
Guest
 
Posts: n/a
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.
  Reply With Quote
Old 2nd January 2012, 05:40   #103  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 912
Quote:
Originally Posted by amtm View Post
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).
Stereodude is offline   Reply With Quote
Old 2nd January 2012, 07:07   #104  |  Link
amtm
Guest
 
Posts: n/a
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.

Last edited by amtm; 2nd January 2012 at 07:14.
  Reply With Quote
Old 2nd January 2012, 09:32   #105  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,245
Can delaycut handle mp3 files (or is mpa limited to mpeg-1 layer-1 and mpeg-1 layer-2 audio)?
because if I run:
Code:
delaycut -fixcrc fix -out "D:\Encoding Output\testNew.mp3" "D:\Encoding Output\test.mp3"
on this 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
Code:
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)
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 4th January 2012 at 09:40.
Selur is offline   Reply With Quote
Old 2nd January 2012, 16:16   #106  |  Link
pandv2
Registered User
 
Join Date: Sep 2011
Posts: 34
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.
pandv2 is offline   Reply With Quote
Old 2nd January 2012, 16:51   #107  |  Link
amtm
Guest
 
Posts: n/a
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.

Last edited by amtm; 2nd January 2012 at 17:51.
  Reply With Quote
Old 2nd January 2012, 18:40   #108  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,245
Quote:
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.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 3rd January 2012, 05:51   #109  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 912
Quote:
Originally Posted by amtm View Post
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.
Stereodude is offline   Reply With Quote
Old 3rd January 2012, 15:00   #110  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,155
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).
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is online now   Reply With Quote
Old 3rd January 2012, 18:35   #111  |  Link
amtm
Guest
 
Posts: n/a
Quote:
Originally Posted by Stereodude View Post
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.

Last edited by amtm; 3rd January 2012 at 18:39.
  Reply With Quote
Old 3rd January 2012, 19:23   #112  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
Quote:
Originally Posted by amtm View Post
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..

Last edited by phate89; 3rd January 2012 at 22:08.
phate89 is offline   Reply With Quote
Old 3rd January 2012, 22:18   #113  |  Link
amtm
Guest
 
Posts: n/a
Quote:
Originally Posted by phate89 View Post
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.

Last edited by amtm; 3rd January 2012 at 22:22.
  Reply With Quote
Old 4th January 2012, 00:57   #114  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 912
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.
Stereodude is offline   Reply With Quote
Old 4th January 2012, 01:37   #115  |  Link
amtm
Guest
 
Posts: n/a
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.
  Reply With Quote
Old 4th January 2012, 09:50   #116  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
Quote:
Originally Posted by amtm View Post
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...

Last edited by phate89; 4th January 2012 at 10:01.
phate89 is offline   Reply With Quote
Old 4th January 2012, 15:59   #117  |  Link
amtm
Guest
 
Posts: n/a
Quote:
Originally Posted by phate89 View Post
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.

Quote:
Originally Posted by phate89 View Post
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.
  Reply With Quote
Old 4th January 2012, 21:21   #118  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
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)

Last edited by phate89; 4th January 2012 at 21:23.
phate89 is offline   Reply With Quote
Old 4th January 2012, 22:20   #119  |  Link
amtm
Guest
 
Posts: n/a
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.
  Reply With Quote
Old 4th January 2012, 22:43   #120  |  Link
phate89
Registered User
 
Join Date: Apr 2009
Posts: 153
Quote:
Originally Posted by amtm View Post
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..

Last edited by phate89; 4th January 2012 at 22:52.
phate89 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:41.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.