Kelsey Hudson - kernel mailing list account wrote:
> > Sorry, but I have to say that that has to be the dumbest idea I have ever
> > seen.
>
> Depends.
>
> > Reading audio off of an audio CD is not a perfect process. If you read the
> > Audio CD specification you'll notice that the best resolution you can get is
> > 1/63 of a second (since every frame is 1/75 of a second). So to fix that
> > problem you need things like jitter correction algorithms (unless your CD-ROM
> > already does it) and algorithms to correctly get around scratches.
>
> He read the white book. :)
>
Actually, I think I read a condensed version of it and also picked up stuff from
various good CD programs (CDR-Win actually, which BTW, runs nicely under Wine if
you have an old unsupported drive). Also, I think cdparanoia had some good
documentation (or maybe it was something else).
>
> > Trying to put all that crap in the kernel is pretty dumb. And if you just do
> > a half-assed job and only let it work for perfect non-scratched CDs on
> > CD-ROMs with built-in jitter correction, then we will have even more
> > half-assed MP3s with pops and skips in them.
>
> I don't know HOW many MP3s I have with pops and skips, but every single
> one bugs the crap out of me. Even worse is the BAD JC algoritms or
> doubling JC algorithms on corrected drives! Those produce whine and hiss
> in the high end and make me want to find out who encoded the MP3 and take
> his computer away from him.
>
Yes, and this is exactly why we don't want to export WAV files from kernel space.
It will just make more crappy MP3s and CD copies.
>
> > By far, the best thing to do is keep this crap OUT of the kernel. The
> > cdparanoia program can do just about anything you want, and NEVER pops or
> > skips even on shitty drives. If you are making MP3s of CDs I strongly
> > suggest that you use cdparanoia and a good encoder.
>
> Never is a big word :) but i agree, this stuff needs to stay out of kernel
> and remain in user-space. As far as encoding goes...get the best encoder
> you can. and that usually means the slow ones. the slow ones do MATH to
> see what algorithm to use given that time, which equates to a better MP3.
> or if you are one that could care less about sound quality, then by all
> means, encode with shitty ripper and encoder. But, if you are doing that
> then you might as well be listening to 8 track tapes, as that is about the
> quality one could expect from something like that.
>
Actually, I have never heard anything noticeable with CD-Paranoia. One nice thing
about CDP is that it displays a bar graph showing what it is doing.. a space for
perfect, a - for jitter correction required, a + for an "unreported loss of
streaming/other error in read". It seems that a + doesn't really affect the audio
(I believe it is corrected). If you see a "V" though, you are in trouble.
So as this pertains to the kernel:
I am strongly against bloating the kernel with code like CD-Paranoia or even with
code providing hooks for error correction. Someone earlier brought up the fact
that everything in UNIX is a device... well, except for network drivers and
CD-ROM tracks. He does have a point, it seems silly to not have devices for
CD-ROM tracks.
I would like to see kernel support for multiple sessions and multiple data
tracks. It is very silly to have /dev/cdrom's contents be the last session
recorded on the disk, with no flexibility.
With that said, exporting audio tracks is a bad idea. Many CDs have audio in
pre-gaps and all sorts of crap that is better handled by a program that can read
the TOC itself and decide what to do. Trying to enforce a certain policy is not a
good idea in this case.
-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:13 EST