Am Mittwoch, den 24.08.2005, 14:11 +0200 schrieb Alexander Larsson: > In general i think the cdda backend is pretty silly. I'm not sure how > normal users will find it useful. Which is why we disabled the old one > by default and handle cdda:/// uris by launching a cd player.
My point is that a normal user does not need to know that theres's a difference between data and audio cds. It's exactly the same medium! How would a user who has never ripped a cd do it? First idea is: copy them from the cd to a folder, as he would do with a data cd. And don't tell me that's not the case. I have observed it several times. > For actual ripping of songs, an app like sound-juicer seems much better > to me, its easier to understand and you need to do less manual work > (just click one button and it rips to your collection). All a cdda:// > backend does is pretend like these are normal files. I mean, they take > far longer to read than real files, and things like seeking in them > isn't really workable. There is not that much difference in work amount between the two types. When ripping a whole cd, you either select all tracks and then copy (if you want the original wave files), or just drag one of the folders (MP3, Flac, Ogg) to its destination. Sound Juicer may require a bit less work for this task, but the cdda method is faster when copying only one track, because you need to deselect the unwanted ones first in sj. Let's call it a draw, okay? Don't get me wrong: the module is not intended to replace sj, which is great in what it does. If you want to rip your collection of cds, this is the tool to use. But for novice users, the module makes the task easier by providing a more intuitive way. Btw, if I had never heard the term "cd ripper" I would not dare to run it with a disc in the drive. "what does it do? rip the disc apart?!" > For a feature of such a limited use (imho) I think adding a gstreamer > dependency is a problem. I mean, we're already having problems with apps > like the gimp not using gnome-vfs due to its orbit/bonobo dependency. > Being able to load vfs files with the gimp is clearly more important > than a cdda backend. I know this dependency sucks, and I suggest to make it a seperate module (does gnome-vfs-extras still exist?). That would require all header files for building a module to be installed in the include path. 2.10 does not do this. Is/will it be fixed in cvs? _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
