Re: [gfvs] cdda backend

[David Zeuthen <david fubar dk>]

On Mon, 2007-12-17 at 19:04 +0000, Bastien Nocera wrote:
> > > 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.

Correct, seems there is no way to tell gio's stream objects how they
should behave and it's unclear to me whether they should have
functionality to do this. The closest thing in POSIX would be the O_*
family of flags that you can pass to open(2) or the fcntl(2) system
call. So either 

 - you want to pass flags at stream creation time (e.g. pass flags
   to g_file_read)

 - have an operation on GInputFileStream to set/clear flags.

Am unsure whether there should be a dedicated SKIP_SCRATCHED_AREA flag
or whether it should overload a standard one. We should probably also
default to !SKIP_SCRATCHED_AREA.

Now, common sense dictates that it's probably not alright to add such
public API to gio with the cdda:// backend being the only user; let me
try to think of other users. Seems like we need some equivalent of being
able to pass O_SYNC, O_DIRECT, O_NOATIME? Alex?

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

Sure, this is fine with me. So I think the easiest way to do this is to
make the cdda just use libjuicer (if Ross is going to make it public)
and tell it to only read / watch the local cache it maintains. E.g. tell
it to never go to the network.

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

So this would just work if we had libjuicer and I could make it watch
the metadata cache it maintains. Sounds OK?

> 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 ;)

OK, sorry for not being clear about this. Nothing like violently
agreement :-)

      David