htrd;285783 Wrote: > > Where does the gap come from? I assume (and I am sorry I still havent > had a > chance to try your plugin...) it is because your correction filters > have > some intrinsic delay, so the end of one track has a reverberation tail > which really should be mixed into the start of the following track. Is > brutefir discarding it? I believe the Inguz convolver saves the tail to > a > file, so it can be picked up by a subsequent convolver process. > Yeah, brutefir has a delay to calculate the first few "blocks". This delay can be changed by choosing the filter length and number of filters. More filters with shorter length result in a smaller gap, but it is not possible to completely remove the gap. Right now the plugin should only be a frontend to brutefir and no wrapper around it, so storing output and prepending it to the next stream would be difficult. Next problem would be that the gap each track starts with must be removed prior appending it to remaining data from last track. I tried to skip blocks with the flac process that encodes the brutefir output, the problem is that flac only supports skipping of data if the size of the audio stream is provided as parameter, so no luck with this. Still I would try to fix this. If it is possible to calculate the length of the brutefir output, gapless playback should be possible and the CPU load could be dropped as well.
htrd;285783 Wrote: > The brutefir source looks.... um.... challenging. Don't know, I am not into C or C++, so I did never checked out the source. Perl was quite challenging for me as well. I am more the Java and Ruby guy :) So I will not be able to tweak brutefir in any way... -- Klaas ------------------------------------------------------------------------ Klaas's Profile: http://forums.slimdevices.com/member.php?userid=8026 View this thread: http://forums.slimdevices.com/showthread.php?t=31620 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/unix
