Log in

View Full Version : Cracks in Audio edits.


tin3tin
29th October 2011, 10:05
I remember some years ago people here where discussing the best way to deal with audio clicks(sounds like a pick-up beeing placed on a record - if anyone remembers that sound? :))in splices, but I can't find the thread. Do anyone remember it? And if not, would you just do 2 frames dissolves?

IanB
29th October 2011, 23:22
Yes hard cutting audio can result in clicks, especially when the last sample of clip1 is a high positive value and the first sample of clip2 is a high negative value.

A very short dissolve (1ms) from clip1 to clip2 fixes the problem very nicely. It involves a bit of stuffing around with DelayAudio(0.001), ChangeFPS(1000), Dissolve(..., 1) and AudioDubEx(OrigVid, Last).

The cheap solution is a 1 frame dissolve at normal speed (40ms).

tin3tin
30th October 2011, 16:23
The cheap solution is a 1 frame dissolve at normal speed (40ms)
Thanks! :)

DelayAudio(0.001), ChangeFPS(1000), Dissolve(..., 1) and AudioDubEx(OrigVid, Last)
Sounds complicated... any chance that this procedure would be integrated into the Avisynth splice routine?

StainlessS
31st October 2011, 01:47
Just an audio novice viewpoint, but if Splice could nullify (ie make zero), audio samples both before
and after spice, would this not pretty much qualify as zero crossover and not produce a 'crack',
might be good practice anyways to force a zero crossover, you aint gonna lose much
anyway on one/two audio samples, all you are likely to lose perceptually is the 'crack'.

EDIT: I think I will enforce this in "prune()" anyways (or at least see if I can spot problems
in doing so).

Ghitulescu
31st October 2011, 09:33
Clicks may always occur if the audio is compressed, and in some occasions also when the audio is not compressed.
The reason is the "time granularity" and framesizes of both audio and video.
The way hardware edit suites solve this issue is to blend the two audio frames at the junction, with decoding/encoding if compressed audio.

StainlessS
31st October 2011, 13:00
@Ghitulescu, Thankyou for that, would you have a recommendation for duration/sample-count to eg
fade to zero on either side of a splice. I am aware that audio compression uses 'audio frames' but am
not aware of a typical duration for such, maybe eg 10ms or thereabouts, also is the duration of a
typical 'squeak', that of the audio frame duration?
Thankyou for your time.

Ghitulescu
31st October 2011, 13:05
It depends on the compression algorithm, what duration an audio chunk has. For some algorithms, the time granularity is not even constant, if they encode eg based on size or VBR.

StainlessS
31st October 2011, 13:18
Thankyou, I should have spotted IanB's
A very short dissolve (1ms) from clip1 to clip2
I think I shall try to implement fade to zero (either side) at default 1ms and perhaps expose
an argument to allow user selection perhaps eg 0ms (off) and maximum capped at video frame duration.

IanB
31st October 2011, 23:54
Yes as 1ms corresponds to 1 cycle of 1000Hz, a 1ms fade out and in across the splice should be imperceptible compared to a 1ms cross fade. The logic involved is certainly simpler.

The goal is to avoid any nasty step impulses which result in a singularity when doing a FFT (which most audio compressing relies). The loud click is the ham fisted result of the codec trying to express the step level change. It ideally would be a high amplitude single half cycle of 24000Hz (F.Nyquist). Instead you get a big mash of energy at lots of aliased frequencies.



And maybe an adaptive approach could be applied to avoid doctoring clean splices (ones that belong together) i.e.
If sample1[last] ~= sample2[0] do nothing else fade. (~=, approximately equal, possibly like sample1[last]>>8 == sample2[0]>>8)

StainlessS
1st November 2011, 01:16
The goal is to avoid any nasty step impulses which result in a singularity


WTF, now I have to worry about creating a black hole, I heard them things can be dangerous.


And maybe an adaptive approach could be applied


Thanks, I like that. :thanks:

Have changed my mind about capping at frame duration, might get tricky figuring out what
to do for a single frame trim/splice, fade in/out/both, think perhaps best to cap at
half frame duration or just below.

StainlessS
2nd November 2011, 22:52
@Tin3Tin,

Have got Prune() doing float audio fade to zero across splice, (not quite done 16 bit, others will I think
not be supported, will in future require one or other), seems to work pretty good.
I've also implemented fade in and out of first and last frames, dont know if this would be required,
or would that be benefical, as implemented it is not separably controllable, what are your thoughts.
Implemented to cap at half frame duration, and controlling arg (float) is specified in milliseconds
(although you could make it less than a millisecond).
Also found a bug in Prune(), "Rx(0)" should result in a single frame @ zero but selects the entire
clip.
Anyway, I'll probably get a temp version compiled and post a link here if you would care to have a play,
and perhaps give any thoughts or reservations you may have, probably within a couple of hours.
Will also include source if someone wants to dig around.
Looks quite good in a modified Prune_Colorbars_test.avs with ideally lower frequency wavforms
using eg sine/square wave etc and seeing the results via the AudioGraph plug. :)

IanB
3rd November 2011, 01:31
For the fade in/out approach there is not much point in going beyond 25milliseconds (Half cycle of 20Hz). This allows removal of an potential singularities.

However as you increase the duration, the effect can become obvious as a "woof" type of noise. With (un)ideal conditions the "woof" can be heard at about 5ms to 10ms. With shorter durations the strength of sub-woofer effects that coincide with the fades may be diminished, i.e. a good strong thump becomes a little watery. But this implies the effect crosses the join and probably should not have been processed in this manner.

For longer durations a cross fade is a better approach, but this implies having audio samples available after the end of the video for clip 1 and before the start of the video for clip 2. Sacrificing a video frame or so to achieve this maybe acceptable depending on content.


I would think the hard work in the plugin is calculating the activity points, doing the actual fade for each sample format would be a 5 way case statement with the same algorithm applied to 5 data formats.

StainlessS
3rd November 2011, 04:56
Hi Tin3Tin, find below link to temporary toy, will be deleted at some point within next few days.
Sorry, on FileFactory.com, Mediafire keeps giving me invalid file messages today, have not
had problems with them since the day I Joined Up, (which was a nightmare).

EDIT: Link Removed. See next post.

I think it should be OK, have not tested extensively. Bit of a relief to get it working as I spent several
hours just staring at it and not having a clue where to start (EDIT: actually you could probably make that days).
Anyway, have a play and see if it suits you. :)

@ IanB,
I did implement the adaptive approach you mentioned, however, I did not like the method suggested, eg
$100 and $0FF (256 & 255) would be considered different but $100 and $1FF (256 & 511) would be same.
I've used absolute difference but I dont know if I should have been careful around zero (+ve,-ve). Anyway,
source is in the box if you would like to show me the error of my ways.
EDIT: I guess ((x + 0x80)>>8) would fix some of the above.

Got to try and get some sleep now, I'm knackered.

Enjoy.

EDIT:-
For the fade in/out approach there is not much point in going beyond 25milliseconds (Half cycle of 20Hz). This allows removal of an potential singularities.

I think I will leave it capped at half frame duration but point out the above in docs, it makes such pretty pictures
in the demo with a longer fade.
@Tin3Tin, The 'FADE' variable in the demo script is set to 50ms (10FPS), for the pretty pictures, you might like to
just use the default 1 or thereabouts, but it aint as pretty.

EDIT: Half frame duration @ 60FPS is only 8ms, would not want to allow above this though as I would have exactly
no idea what to do with a single (or even double) frame splice If I allowed a cap of 25ms.

StainlessS
5th November 2011, 08:42
Have posted link to new Prune() v1.01Beta2 here:
EDIT: Link removed.

Implemented Float, Int16, Int32 for fade. Other Audio format supported without fading (must switch off fading).
New supports bool's, FadeIn, FadeSplice, FadeOut, but all using same Fade arg in milliseconds.

Capped Fade time to 25 ms or half frame duration, whichever is the lesser. :)

Prune thread here:- http://forum.doom9.org/showthread.php?t=162446

tin3tin
8th November 2011, 21:12
Been away for a week - will test when I have a spare moment.