Re: [gfvs] cdda backend

[Bastien Nocera <hadess hadess net>]

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