Re: [gfvs] cdda backend

[David Zeuthen <david fubar dk>]

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.

> > > 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.

> data which won't carry over to changes in applications.

What does this mean?

> 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?

      David

[1] : $ python wavdumper.py ~/.gvfs/CD\ Audio\ on\ sr0/Track\ 2.wav 
File: /home/davidz/.gvfs/CD Audio on sr0/Track 2.wav (61083910 bytes)
Chunk at pos 20: id = "fmt ", length = 16 bytes
  Format Chunk
  Data format: Uncompressed PCM
  Channels: 2
  Sample rate: 44100 Hz
  Average bytes per sec: 176400
  Block align (bytes): 4
  Bits per sample: 16
Chunk at pos 44: id = "LIST", length = 66 bytes
  List Chunk, id = "INFO"
  Chunk at pos 56: id = "ISFT", length = 54 bytes
    Software: gvfs-cdda using libcdio 0.78.2 i386-redhat-linux-gnu
Chunk at pos 118: id = "data", length = 61083792 bytes
  61083792 bytes sample data
  15270948 samples
  346.280 seconds