Hi Max,

Max Kellermann wrote:
>> Do you know of a better way/have a better idea for enumerating the
>> subtracks instead of "track_xxx.flac" like i did atm?
> 
> No, although I'd probably just call it "1", "2", ... without any
> prefix/suffix.

I figured with the prefix the files get sorted in a correct order.. but
this is cosmetical and should be configurable as soon as we have cue
sheet support.

> For now, we could say: those "virtual" sub-songs can only be one level
> above the main song (which is enough for supporting CUE).  So if the
> file cannot be found, try its parent.  If that's a file, handled by a
> decoder plugin which can handle sub-songs, call method "sub_decode()"
> (instead of file_decode()?).  Just an idea.

So we would have two new api extensions:
sub_decode() and scan_directory()?
That's ok for me and i'll implement it that way.

>> This should be no problem with the scan_directory api extension.
>> Though i now have to include tag.h, song.h, songvec.h and dirvec.h to
>> flac_plugin.c. Is this ok?
> 
> Doesn't sound perfect yet, but good enough for now.

We could make the scan_directory() method point to the flac_cue_track()
method and extend the the tag_dup method to tag the (virtual) files
accordingly.
That way the code would be separated i think and the includes shouldn't
be necessary anymore.

>> 3) Write an parser on your own.

> Doesn't look too hard, does it?  If we write a good library, others
> might adopt it in the future...  that'll be the first CUE library with
> a decent API then.

Hm.. i think it would be a bit hard for me but i got used to C the last
weeks so it could be done i guess (also it'd take some time..).
The more general problem is that i do not really have a clue about
writing a parser. I figured to make something like a fixed size hash
table according to the entrys (like "PERFORMER", "TRACK", etc.) and then
have a linked list with entrys attached to the table (similar to
separate chaining).
But maybe there's a whole different "general" approach to parsing i am
not aware of.

> Maybe we can fork the cuetools library?

There are some good parts which could be used but the parser itself is
written in yacc/bison which i don't "speak". :)

Regards,

Jochen


Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team

Reply via email to