[LAD] [Ann] Folve: Fuse file system that convolves flac files on-the-fly

Henner Zeller h.zeller at acm.org
Wed Sep 19 18:49:32 UTC 2012


On 17 September 2012 17:16, Paul Giblock <pgiblox at gmail.com> wrote:
>
> On Sep 17, 2012 8:04 PM, "Henner Zeller" <h.zeller at acm.org> wrote:
>>
>> Hi,
>> On 16 September 2012 09:10, Fons Adriaensen <fons at linuxaudio.org> wrote:
>>>
>>> On Sun, Sep 16, 2012 at 12:46:42AM -0700, Henner Zeller wrote:
>>>
>>> > Over the week or so, I've build some fuse filesystem filters flac files
>>> > on-the-fly
>>> > using the zita convolver. This makes it real easy to play
>>> > around with files and filters. In particular with systems that
>>> > otherwise
>>> > don't support stream convolving, but just can read files.
>>>
>>> Interesting project...
>>>
>>> One thing: when skipping forward (or seeking in general)
>>> there's no need to convolve all data up to that point.
>>> If P is the new position and L is the lenght of the IR,
>>> then just call Convproc->reset(), seek the input file to
>>> P - L (or 0 if P < L), and convolve up to P. You're
>>> computing a FIR filter, so no more history is required.
>>
>>
>> I know. The only reason for doing what I am doing is entirely because of
>> the filesystem semantics.
>>
>> On the filesystem level, I don't 'see' seeks to audio frame positions but
>> _only_ file positions. Since the input and the output is a compressed flac
>> file, the relationship cannot be predicted - this is why I have to walk up
>> to that point to present a consistent view of the file (in particular if
>> that file is mmap()ed or if users jump around in it, this is important).
>> (this would be different if input and output was wav where the
>> relationship is clear; but wav doesn't provide such a rich header format, so
>> that the user in media server that display tags and images would be bad).
>>
>>>
>>> If the seek involves an output discontinuity for the user,
>>> you could even just call Conproc->reset(), seek to P, and
>>> proceed normally. The result will be as if there was only
>>> silence before P.
>>>
>>> Ciao,
>>>
>>> --
>>> FA
>>>
>>> A world of exhaustive, reliable metadata would be an utopia.
>>> It's also a pipe-dream, founded on self-delusion, nerd hubris
>>> and hysterically inflated market opportunities. (Cory Doctorow)
>>>
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev at lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>
> Have you considered OggPCM? Perhaps it has a constant enough bitrate while
> still providing rich tags. Not sure how well supported it is though...

Thanks for the tip. I think OggPCM sounds like a good way to represent
the data with predictable seek behavior. Right now, i didn't run into
the problem for flac files with my current usage pattern (=not much
seeking :) ) though, but it might be a good feature in the future. The
beauty if encoding flac -> flac right now is, that I can just provide
the original headers verbatim to the new file, so I don't have to
worry about extracting the header and re-coding it into a different
header format and probably loosing half of the interesting information
on the way (e.g. libsndfile does not support cover-pictures).
(All my audio files are flac anyway).

Where it immediately can be useful: when reading ogg-vorbis files. I
do re-coding ogg-vorbis -> flac right now in Folve, because apparently
libsndfile needs to read the full input before it can generate the
compressed output -- which is not what I want, so I encode as flac to
have the immediate 'streaming' capabilities. In that case using the
same ogg container but having the data in PCM might be the better
choice; Have to check that libsndfile supports the OggPCM combination.

-h



More information about the Linux-audio-dev mailing list