[Clam-devel] Ogg seeking

[David García Garzón]

I was unsure of either option. I am still unsure. In summary, I am just 
refactoring both until they blend.

On one side sndfile has already seek, float wavs, lockfree support and nicer 
interface for multichannel than MultiChannelAudioFile* but, on the other hand 
it still lacks ogg, mp3, error condition safety, and, important, unit tests 
to evolve it without regressions. On the other hand, audiofileio already 
implements sndfile, ogg and mp3 support, is test backed and the error 
conditions are properly handled (and tested).

I aggree that complexity of sndfile plugin code was still not that high than 
audiofileio but, believe me it had already a very high complexity/feature 
ratio. Adding features required refactoring and so i did. Now i think that 
the new features are completely clear and abstracted out as helper classes 
but the codec itself. To see how to abstract the codec i took a look to the 
audiofileio stack. But i applied the understand by refactor principle ;-) and 
soon i had a higher level interface was not that far of what we where leading 
sndfile to. Being backed by tests was nice in this case.

Being both interfaces that similar, moving features from one to another seems 
easy so we have many options now. Adding seek was a couple of lines for each 
codec (not with mp3 but that's a mad problem, not audiofilein). It is not a 
double effort, being able to address codec complexity and lockfree complexity 
in separate code bases has been very insightful to me.

BTW, i just added a very preliminar seek for mp3. A better solution is needed 
as currently we are navigating along the mp3 sequencially and just forward so 
it is too expensive, meaning being stopped by jack depending on which jumps 
you do. In Miguel's code differentiates constant rate, variable rate with 
xing header (which i think acts like an index) and and 
not-indexed-variable-rate. In the later case we should build the index 
ourselves.

Let's talk about it tomorrow. Maybe we have some spare time then.


On Wednesday 03 June 2009 07:48:30 Pau Arumí Albó wrote:
> David, are you sure that refactoring and enriching
> Mono/MultiChannelFilePlayer is worth the efford, compared to keep
> SndfilePlayer evolving (and changing its name)?
> The latest was ment to be a replacement using a much simpler approach.
> Anyway, lets talk about it at the office.
>
> P
>
>
> El dt 02 de 06 de 2009 a les 15:11 +0200, en/na David García Garzón va
>
> escriure:
> > At last, so many refactorings lead to features.
> > * MonoAudioFileReader seek control that seeks on PCMs and OGGs, not in
> > MP3 yet * MonoAudioFileReader has time, frame and progress controls (all
> > formats)
> >
> > The idea is merging most of the SndFile stuff. Look free disk access will
> > force to evolve even more the AudioCodec::Stream interface which is
> > perfect.
> >
> > Regarding MultiChannelAudioFileReader, i really learned to hate the
> > channel selection complexity which i guess nobody uses but the tests and
> > few examples. It has no sense at all selecting the channels you want to
> > write on a multichannel file. And if you are reading just ignore the
> > ports. I propose to implement the channel policy of the one
> > SndFilePlayer/Writer. I would also suggest to name it
> > AudioFileReader/Writer, that is, removing the 'MultiChannel' prefix.
> >
> > So the related TODO's on the stack are:
> > - Integrate LockFree features (almost extracted as classes already)
> > - MP3 seek (i guess that codec's lenght computation has some hints)
> > - Being able to write Float wavs (means racionalizying format selection
> > as in SndFileWriter).
> > - Refactor the codecs
> > - SampleRate adaptation
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel