Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Convolution filtering
04-05-2020, 15:39
Post: #21
RE: Convolution filtering
(04-05-2020 10:02)simoncn Wrote:  Assuming there is a delay of 32768 samples, the input is padded with 32768 samples of silence at the end and the output has 32768 samples removed from the beginning.

Presumably, the click you mentioned in the original post, could be caused by the start of the track beginning in the 'middle' of some audio.
Now, what if you could add the silence to the beginning of the track before removing it after convolution? That should result in the output of the audio track complete and logically no click, perhaps.
So, you can by replacing apad with adelay as below.
Nb - the capital S is important. Lowercase s indicates milliseconds.

-lavfi "adelay=delays=32768S:all=1,afir=gtype=gn,atrim=start_sample=32768"

(04-05-2020 10:02)simoncn Wrote:  I don't know whether 32768 is always the correct value to use.

Expanding on the finding of tgb, perhaps this samples value of 32768 should reflect the number of samples/taps used to generate the convolution file.

The above are all musings, however, as I don't use ffmpeg for convolution and have not performed any tests.
Find all posts by this user
Quote this message in a reply
04-05-2020, 18:04
Post: #22
RE: Convolution filtering
If silence is added to the beginning of the track before convolution, this added silence would need to be removed after convolution in addition to removing the convolution delay. It might be worth trying this.

I am not well versed in the theory of convolution and I don't use it myself. Fortunately, MinimStreamer provides enough control options to enable others with more expertise to try different settings and refine the process.
Find all posts by this user
Quote this message in a reply
05-05-2020, 21:14
Post: #23
RE: Convolution filtering
Quote:-lavfi "adelay=delays=32768S:all=1,afir=gtype=gn,atrim=start_sample=32768"

Does the above behave similarly or better than the below?

Quote:-lavfi "apad=pad_len=32768,afir=gtype=gn,atrim=start_sample=32768"

I couldn't stand the suspense any longer and so I tested it myself.
The answer is clearly no, in fact it is worse, or rather, has no effect on the gap.

Quote:... perhaps this samples value of 32768 should reflect the number of samples/taps used to generate the convolution file.

Now this does have some merit if the results of my testing is evidence. It may also depend on how the FIR filter is generated.

More to come ...
Find all posts by this user
Quote this message in a reply
05-05-2020, 22:28
Post: #24
RE: Convolution filtering
(04-05-2020 07:45)tgb Wrote:  As mentioned in this thread => http://forum.minimserver.com/showthread....4#pid36514
Convolution leads to gaps... BUT no big deal, according to my rough tests & understanding, you end up with gaps only if the number of taps used to generate the convolution file is too high (I use rePhase to generate the .wav file).
Above 131072taps => gaps. The higher the number of taps, bigger is the gap.
At 131072taps : fine for me. Gaps are tiny, thus I found it si so close to gapless that I kept this convol file @ 131072.
Below 131072taps, I expect the gap to be even smaller, thus roughly gapless.
Dear all & Simoncn,
I quote myself to notice that what I mentionned was wrong. Sorry about the confusion I created.

The gaps I got were due to a wrong usage of rePhase to generate the convolution file.
I generated a "stereo" file, instead of a "mono", which is the correct way to proceed.

So, I generated a correct convol file, rather big one : 64bits IEEE mono 384kHz, 1Mo size, 131072taps.
Now, regarding the gaps with this file : nearly no more gap issues.
Nearly because :
- a micro-gap remains between the 1st & the 2nd track of a playlist/album
- but NO gap on the following tracks of the playlist/album.
This unique micro-gap is easy to listen on a continuous mix album for instance, but it is a no pb with albums with standard songs or classical live recording etc.

With such a big convol file, my NAS (DS415+) uses 1.2-1.4%CPU to run the convolution, which is very low & cool.
Sorry for my mistake above.
Rgds

Optical LAN & hifi setup : https://www.dropbox.com/s/757c488ovo1zw6...0.pdf?dl=0
Find all posts by this user
Quote this message in a reply
05-05-2020, 22:55
Post: #25
RE: Convolution filtering
What is your -lavfi setting?
Find all posts by this user
Quote this message in a reply
06-05-2020, 18:12
Post: #26
RE: Convolution filtering
Quote:... perhaps this samples value of 32768 should reflect the number of samples/taps used to generate the convolution file.

I have repeated the tests I conducted yesterday with the same favourable results.

I used a couple of tracks from Janet Jacksons' All For You album.
Track 10 Lame ends with the word 'see' and track 11 Trust a Try begins with the word 'trust' and these tracks would normally segue with no gap.
I used a 32768 tap FIR LPCM wav file, generated by Rephase, in the streaming options together with the pad and trim values also set to 32768 samples.

Playing these tracks in sequence, it is clear to hear the truncation of both words of these tracks, albeit with an almost non existent gap of silence.
Changing the pad and trim values up and down would either reduce the truncation of the words, but not eradicate it, or reproduce the click between the tracks.
Eventually, I found the perfect value which produced a stream of audio almost indistinguishable from the non-convoluted stream.
This value was 16384, half the value of the 32768 tap file. Coincidence?

I repeated the tests but this time with a 65536 tap filter and found that the perfect pad and trim value was 32768. Not a coincidence.

At this point, I recalled that Rephase offers an option to 'centre' the start of the impulse response within the FIR file. The default option was set to middle and Rephase reported the IR offset as 16384 after generating the 32768 FIR file.

Unless I am completely misinterpreting all of the above, I have concluded that the FIR generated by Rephase contained nothing significantly useful in the first 16384 samples. These insignificant samples are duly reflected at the beginning of the convoluted output file and therefore removing these samples does not affect the audio content. I do not, however, have any explanation regarding the padding other than knowing that without it the word at the end of track 10 is truncated.

I'll end by stating that my comprehension of convolution is very, very basic and I do not understand the 'magic' that occurs when applying the pad and trim values. It is purely based on the above listening tests.

nb - FIR filters generated by other products may be similar to Rephase with regards to the impulse response offset but YMMV.
Find all posts by this user
Quote this message in a reply
18-05-2020, 21:37
Post: #27
RE: Convolution filtering
Hello,
Thanks Alandbush & Simoncn for your ideas above.

Streaming from Minim with convolution is 100% fine now.
No more missing part at the start, no more gaps, with a convol file based on 262144 taps, running on NAS (DS415+, with only 3-3.5% CPU used by this process).
Flawless, too cool ! Wink

Like you Alanbbush, I don't understand the "why", but the following string in stream.options is the good one as you mentioned, thanks Simon for this trick :
convOut=-i /volume2/Data/Convol/impulse47fS*.wav -lavfi "apad=pad_len=131072,afir=gtype=gn,atrim=start_sample=131072"

Sum up :
apad & atrim functions. Thanks Simon.
Same value "x" for both functions => x = 0.5 * (the number of taps in your convolution file). As simple as that.

Based on that, you can use the maximum number of taps.Big Grin
In my case, as you can see in th string above, I could go up to 262144taps.
Above, unfortunatly rePhase crashes, even when I use the trick to close/reopen rePhase b4 generating the file.
BRgds

Optical LAN & hifi setup : https://www.dropbox.com/s/757c488ovo1zw6...0.pdf?dl=0
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)