Audio CD File System in the Works

Please use lossless compressed formats as default: flac or ape (better), not wav. Help users to save up their disk space

untrue.
less than 5% of CPU even on slow (1st or 2nd gen Pentium) machines. and not for "nothing", but for saving space.

much more players supports mp3 :)

You forgot, that a lot of FS supports transparent data compression.
NTFS for example

Couldn't there be an option to encode the wav files to some other format if you drag them to the Desktop or even a prompt when you insert a disc?

"Would you like to listen to the cd or copy the files to your hard drive ?"

As Tracker is the one that presents both source and target filesystems and does the actual copying, yes, it could offer to do conversion. That would be a lot better than doing this in the kernel, as Tracker can't take down the entire system and it can use the services of the Media Kit. But it's a clear case of feature creep. This isn't one of Tracker's essential services. If this would be added to Tracker, it becomes easier mentally, to add special case treatment for other things as well.

Any application could watch for volume mounts and offer to convert and copy. "HaiTunes".

Instead of optimizing for storage too early (IMO), you could have a disk space daemon kick in when available space gets low, which would offer to compress your wavs, etc.

You could make a flac daemon and userland filesystem that would make another CD appear, with the same songs in flac format.

It's not necessary to add these things to the in-kernel filesystem or to Tracker.

I'm completely with Jonas on this - the wav is just basically a header to the raw data on the CD.

Haiku is not driven by politics - so proprietary/free distinctions are much less important than level of support. Wav is supported by many more players than flac, and is a better match for the physical format than needing to do constant compression/decompression on the fly.

A daemon that watches for CDs being mounted and offers to convert them to a various choice of formats does seem a pretty transparent approach to me. The CD filesystem should make the raw data on the CD accessible to applications. The best way to present the raw audio data is by wrapping it in a wav container.

Sorry, liilliil, but wav isn't proprietary.

I think Simon's right here - the idea is not to provide a method for ripping audio CDs to files, it's simply a method of presenting the CD Audio data to applications so that they can play it back with minimal effort. There is no space wasting going on since the file will most likely just be streamed straight from the CD, or at worst the whole track will be loaded into mem which is about 30-50MB or so.

If you dragged files from the CD to another disk location it might be nice to have some sort of popup for encoding the files under another format.

*Edit* I've really got to stop replying to posts rather than posting new comments. Damn it :)

This makes no sense, as the file system in question is being read from a CD. It would be pointless, in fact it would be completely wasteful, to compress the files in memory only to have to decompress them when playing from the CD.

Therefore I will assume you don't understand what this file system is actually doing.

As for ripping the CDs to get mp3, flac or ape files to store on the hard drive, that is probably best left for special applications, not the OS itself.

Sorry if this sounds a bit harsh, I was just surprised people were trying to debate with you about compressing the CD audio on a CD file system, since it is a silly idea.

Right. Well at least the soundcard would be involved, but directly from the CD drive. Otherwise how would you hear it ;)

But I'm not sure how this filesystem handles that. Maybe the CDDA works that way when played from the CD Player application.

OK, I understand now. I don't think the waves were created just for ripping. I think they were created because they are easier to use, and it isn't hard to turn the audio files on CDs into waves.

I just think that an average user would pop the CD in, see the nice names on the WAV files provided by the CDDB, and would play those files directly. Therefore the compression would be wasteful. I am pretty technical and when I put CDs in a BeOS system in the past, I just played the wav files, and didn't try to copy them, so I don't think this is unheard of.

In addition where would the compressed versions of the files be stored? In memory? Then we waste memory. On disk? Then we have to keep track of them and maybe delete them if the user didn't want a copy. Plus ripping is a pretty CPU-intense activity. That "5"% you mention can ONLY be for playing compressed files, not compressing them. I wouldn't be happy if I popped in a CD and had to wait 30 seconds (or probably longer) while compressed versions of the files were created.

Maybe the "compress on copy" functionality others talked about would be nice.

But I still think this sort of feature is too complicated and not of the BeOS nature that I understand.

I've never really understood why it is, in Marco/Be's original cdda-fs, that the zero-size files in /Disc/cdda/ are typed "CDDA files" and presented in that folder. Those files do not provide BeOS applications with access to the raw CDDA data, AFAIK, and they are only ever used as cues to the CDPlayer on which track to start playing, which goes about its business with simple SCSI commands to change tracks and start/stop/pause the playback. The analog signal gets sent over that legacy cable from your CD device to a connector on your audio card.

I think that most contemporary computers are strong enough not to need that cable solution anymore, and it does simplify both the user experience (no subfolders in a cdda-fs volume, one file type instead of two) as well as simplify the way to write media players, since you don't have to have write code for interfacing with CD hardware any more. Instead you can focus on fileformats/codecs and interface.

I've done 50/50 listening and ripping over the years, and I like doing both. The cdda-fs works great doing either. I admit that it's easy to forget to compress those wav files when you have a lot of disk space, but that is easily fixed. You can use any tool you like to compress them, or do as I do, just delete them and copy them back when you need them. One of these days I'm going to start making a music library application of some sort.

(DAE! Right, I wasn't clear on the terms. CDDA = Compact Disc Digital Audio, including the standard of PCM-encoded audio, and spelled out in the classic Compact Disc logo. DAE = Digital Audio Extraction. I don't know if that's an official term. I couldn't find a definite answer on Wikipedia.)

Oh yeah, in line with what Urias said, using the wavs for playback I don't have to mute or change the CD volume independently of the volume of the system-level audio mixer: Media preferences/Audio Settings/Audio Mixer. I suppose I could instead adjust the line-out level of the card mixer, but the Deskbar volume icon is connected to the system-level mixer, so it's more convenient to just use that.

BTW, using the wavs (or whatever format) you get the weird bonus of being able to play multiple songs of the CD simultaneously and backwards, should you get the urge to do so, as long as the system can manage and you're not bothered by the noise of your device. :} Not that this matters much anymore, but it was a cool demo back in the 90's.

About "transparency", or seamless integration - like if Tracker would offer to compress files for you when copied from CD to HD - this always comes at a cost, stability, source code maintainability, etc. I believe Microsoft has tried hard to integrate a lot of things and it has cost them in security. Of course, this integration may also be the key to their massive success. The unixes have instead often gone for very clean separation which while technically better has shown less popular. I think we can take the golden path between the extremes, but we've got to be cautious and understand the implications of design decisions.

Do you mean a convert feature like Soundplay's one? Really useful tool, but it's limited to the mediakit translators, Haiku has a wider format support, but seems that SP won't run on it, at least the last time I tried it.

Or a tracker add-on like Massive Picture Converter? Just open selected files with it, select destination folder and convert options, finished.

CDDA-FS support is great improvement to Haiku, thanks!

Janet Kellman, [url removed]