On Mon, 2007-12-17 at 11:37 -0500, David Zeuthen wrote: > On Mon, 2007-12-17 at 16:13 +0000, Bastien Nocera wrote: > > > Sure, and I agree we should all be using GStreamer and all the apps we > > > all use should be using it. But a number apps still don't and there are > > > multiple competing frameworks etc. > > > > Then they're probably using another way of accessing the data, probably > > through plugins for that particular framework, certainly not using gvfs. > > No, of course not. But it's pretty useful to do things like [1]; ditto > for lame and other commandline tools. There's a lot of complaints from > users that the gnome-vfs mounts weren't accessible to plain old POSIX > apps. > > > > I think instead the backend just skips over the scratched area and puts > > > up a libnotify notification (or other out-of-band signal) to notify the > > > user it's skipping over the scratched area (that's how DVD Player in Mac > > > OS X 10.5 does it) > > > > That's not a bad idea for playback, but certainly not of any use for > > ripping. > > Maybe if you explain what you need it's easier to figure out. It's hard > guessing.
In playback mode, you want to skip over broken bits. You'll get a little garble in the output. In ripping mode, you want to try as hard as possible. It's not possible to make the distinction right now, using gvfs. > > > > How do you export the MusicBrainz Disc ID, or FreeDB one? > > > > > > As metadata in the WAV container (see the patch for details; search for > > > "Jailhouse"; it's fine, we can choose another container for the PCM data > > > if you want (AIFF?) > > > > How will you get the metadata? You'll need to use musicbrainz, or > > similar, > > Sure. The point here is that we'll have a desktop-wide mechanism for > obtaining this meta data so each and every app don't need to grow their > own "how to get meta data" preferences dialog. As we discussed on IRC, it's a bad idea to do metadata fetching from the module itself. It's not future-proof, it makes reading the CD do network I/O, it causes problems in terms of architecture as to where to put dialogue for manual problem resolution (2 different CDs with the same ID). Having a way to get/set the metadata in the module would make sense though. It would allow: - renaming the mount point to show a specific name[1] - setting an icon for the audio CD (most likely the cover) - metadata persistance done on the application side (insert CD when on the network, launch app, take network down, remove CD, insert CD, metadata is still there) IIRC, MacOS X does this the same way (ie. it will just be called "Audio Disc" before iTunes gets started up). The main difference would be that I think their module can read from the iTunes database, so it would know about the metadata the second time the CD is inserted, even if iTunes isn't started. > > data which won't carry over to changes in applications. > > What does this mean? - Get metadata in sound-juicer - Modify it - No changes in the listing > > We'll need to blacklist cdda:/ from the gvfs GStreamer plugin to get it > > handled by the proper CDDA plugin from GStreamer, so they do overlap. > > Does GStreamer have the concept of a VFS already? It has a concept of schemes, which are handled by one or more plugins. Eg. a file:/// URI could be handled by the filesrc or the gnomevfssrc right now. It obviously doesn't do directory listings, or anything complicated like that. Also, once the first problem (ripping vs. playing) is sorted, we could switch the cdparanoia plugin of GStreamer to using gvfs for playback instead. Thing I didn't understand at first was that the cdda gvfs module doesn't allow for the audio CD to be accessed if HAL doesn't tell it it's an audio CD. So you can play mixed CDs without the backdraw of stomping on burns. _That_ makes complete sense (and which wasn't clear from your original mail, which is why we came to handbags ;) Cheers [1]: http://bugzilla.gnome.org/show_bug.cgi?id=316403 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list