Re: 2nd track

[Toby Dickenson]

On Tuesday 08 Mar 2011, Toby Dickenson wrote:
> On Wednesday 02 Mar 2011, Mervin Beng wrote:
> > You have 1 file waiting for download:
> > 23.Variation 22.flac
>
> I still have not had a chance to listen to these - I need to lift speakers
> down off wall brackets to use my linear phase filter and the lounge is full
> at the moment.
>
> However, I cant see any glitch in audacity when running both tracks through
> the filter and concatenating the two outputs files, and it sounds quite
> normal when listening on headphones.

I hear it......

--
Toby Dickenson

[Mervin Beng]

As I understand it, after FIR filtering, the two tracks merge ok
visually when viewed on audacity, but there is a discernible audio
glitch.

My observation is that the glitch is less / not noticeable with a T
filter. There are two things which I've thought about:

1. In the sample I've passed you, and other music where track
transition is really a convenient index separating to sections of
music, the next track may start with quite in impulse. In true
'gapless', the current + next track merge, and there is no impulse,
but just a continuation. Could this impulse create any appreciable
click? I've tried some form of very short fade-in (100-400 samples) of
the next track, but results were inconclusive.

2. The tail, as I understand it, consist of one section that
compensates for the truncation at the end of the output stream due to
brutefir delay (lets call it tdelay). Then if your tail_sec = 0.85,
there is additional remaining filter effects beyond the end of current
track (0.85 - tdelay sec worth). At the price of losing the additional
filter tail, could splicing with (brutefir output of current + tdelay
sec of tail to compensate delay + next track, but skipping first
tdelay sec to offset the short tail) get us closer to the gapless we
want? What is lost is the initial effect of the filter on next track,
which is what your longer tail provides. However I think that tail is
sometimes responsible for the audible glitch. With this algorithm, on
true gapless music, we lose some initial room correction at the start
if the music starts at sample 0, but I expect it's not noticeable. On
non gapless music, there should be no impact as most often there is
fade out on current track, some silence, and a little silence before
start of next track anyway.

This strategy requires pre-knowledge of the the filter delay. For T
filter it's 50% of one of the window_min parameters. I'm not familiar
how to get it for L filters.

I guess the real 'ideal' gapless is to send brutefir next track as a
continuation of current track, but I don't see that happening with the
slimdevices artchitecture.

Thanks for your help on this. For now with T filters I am pretty much
glitch free on gapless, but your positive comments on bass using L
filters is what got me to test them out. I will continue testing my
alternative algorithms when time allows.