2011/8/14 Rocky Bernstein <[email protected]>: > On Fri, Aug 12, 2011 at 9:45 AM, Stef Bon <[email protected]> wrote: >>
>> Maybe you should try it. >> >> (as you can read I'm not ready with it, but it works ) > > > I just tried compiling from git sources. I get > make: *** No rule to make target `cdfs-io-thread.h', needed by `cdfs.o'. > Stop. > And there is no C header file cdfs-io-thread.h. Perhaps you meant to add > this to the git repository? (As I write this there is only one initial > commit to the git repository.) > As far a the C coding style and organization, the code looks good! Thanks! I removed a special io thread from the fs, which I use in almost every fuse fs. I've removed it recently from fuse-cdfs, but I forgot this one. I already fixed this. The new version in gitorious is corrected. Please let me know how it works! >> >> Now I have some questions: >> >> a. is there a way to identify the cd uniquely. >> >> Right now it stores >> cached files in >> >> %cache_directory%/tracknr-xx.wav >> >> Now when I unmount, I ant to be able to keep the cached file. I would >> like to have an unique id per readable cdrom, like an uuid per >> partition on a harddisk. Is there one? > > A CD can have a ISRC also known as a MCN (Media Catalog Number). In > practice many CDs do not have this. If I wanted to ensure uniqueness, I'd > probably create a SHA1 hash for each track and do something with combining > that for each of the tracks to form a disk hash. > Yes that's possible, but to get the SHA1 code per track you need to have to read the whole file first, and that's what I want to avoid, you understand? I would like to know how the fuse-fs can take the file from the cache instead of reading the cdrom. So yes the ISRC code you mention can be usefull here. > > The libcdio call read_audio_sectors allows you to read a large number of > sectors in one call. Depending on the CD-ROM driver this may wind up into > several smaller calls. If the CD-ROM support MMC, then read_audio_sectors > turns into a MMC READ_CD call. I don't know that one can be more direct than > this. OK, this stays in the fridge for now. This requires some digging. Stef Bon the Netherlands _______________________________________________ Libcdio-help mailing list [email protected] https://lists.gnu.org/mailman/listinfo/libcdio-help
