On 2009/02/28 15:29, Jochen Keil <jochen.k...@gmail.com> wrote: > Currently i'm working on the scan_directory() method you proposed in one > of your first emails. This isn't to hard to do now and we'll get rid of > several include dependencies. > 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. > > MPD core sources should not include decoder specific headers. But now > > I understand what you meant with "input_flac" on IRC - it'll eliminate > > this dependency. > > Would it be better if i did something like this: > stat() the pathname > on NULL: go one level below > stat() again > until we're either root or have a file. > (haven't tried it yet, maybe i'm wrong on this but after a quick look in > input_file.c i think this might work as well) 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. > 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. > The general approach of scan_directory could be used for the archive > plugin as well i think.. Yes, why not. update.c is full of code which shouldn't be there... > 3) Write an parser on your own. > Here you can find the complete spec: http://digitalx.org/cuesheetsyntax.php > As you can see (and also from cuetools/cdrecord) this ain't an easy > thing to do. 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. > As a conclusion for the cue parser/plugin: > Writing a parser ourselves would be the best option but also the > hardest. I tend to like the cuetools approach best because the specs > didn't change and cuetools seem to be usable in an easy way. What i > don't like though is having a tmp file.. Maybe we can fork the cuetools library? Max ------------------------------------------------------------------------------ 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
