Thanks Ross and Klaus, your explaination help in understanding the hardware options. I will get another gig of ram and see if I can hear the difference.
Current system has a gig and sata internal hard drive and sounds great.
Mike
Current system has a gig and sata internal hard drive and sounds great.
Mike
I'm looking for some help getting a Linux system to play high sample rate files at the native rate. I can use an outboard dac but I don't want the PC resampling. The files are 176.4/24 and 192/24. From what I have found so far the Linux guys are more likely to downsample (what's the point?) I know the Via vinyl audio is supposed to support 192 natively and the Intel HDA also will support 192. If I can just get the stream to the S/PDIF coax connector I'm happy. In reading through this I didn't find anything on this. (I may have missed it with 30+ pages of stuff).
RE HDMI audio. The audio stream isn't isochronous. The audio is buffered and passed as a block in the vertical refresh (or so the Silicon Image guys tell me) so it comes to the receiving device in 60 Hz blocks (for a 60 Hz refresh). Given all of the different clock rates involved getting low jitter from HDMI would be a miracle. The TMDS streams are all self clocking at 10X the pixel rate. The pixel clock is mostly for syncing the pixel start point and can have significant skew with reference to the data lines. Adding audio support was considered a minor thing given the huge data capacity (only 70% of the content is video, a lot is just refresh timing) so they just stuffed the audio in available holes.
And none of the pixel rates/refresh rates vert/horz rates match audio rates exactly so some sort of reclocking pll etc. is necessary to extract the audio from HDMI.
RE HDMI audio. The audio stream isn't isochronous. The audio is buffered and passed as a block in the vertical refresh (or so the Silicon Image guys tell me) so it comes to the receiving device in 60 Hz blocks (for a 60 Hz refresh). Given all of the different clock rates involved getting low jitter from HDMI would be a miracle. The TMDS streams are all self clocking at 10X the pixel rate. The pixel clock is mostly for syncing the pixel start point and can have significant skew with reference to the data lines. Adding audio support was considered a minor thing given the huge data capacity (only 70% of the content is video, a lot is just refresh timing) so they just stuffed the audio in available holes.
And none of the pixel rates/refresh rates vert/horz rates match audio rates exactly so some sort of reclocking pll etc. is necessary to extract the audio from HDMI.
1audio said:
Hi.
You can pass by dmix if you route your pcm stream right to the respective output device - usually these are called hw0 ( 1st soundcard) and e.g. hw1 for the 2nd soundcard.
Of course you need a soundcard which doesn't re-/upsample by itself.
As a good choice for testing basic pcm routing you might want to have a look at aplay - the alsa command line player.
You need to look up the command line paramters:
http://alsa.opensrc.org/Aplay
or the manual pages type > man aplay
something like that could work:
aplay -Dhw:0,0 -f S24_LE -r 192000 test.wav
Of course you need to know exactly the output id (port) of your digital out on the soundcard.
THX for the information about HDMI. It seems that a lot will depend
on the receiver again. I don't understand why it is so difficult to
get a synchronous link in place. It seems that a master clock is and will be mandatory to get all devices in sync.
Cheers
Wine/Asio
Just a note not really germane to previous discussions.
Had the opportunity to check out a bit of Windows compatibility recently, and I'm pretty impressed. An ASIO driver has been implemented for Wine that patches directly into a Jack graph, so you can run many asio-enabled Windows apps as part of your Linux system. I only tried AudioMulch, but apparently many non-trivial apps actually run.
This isn't terribley relevant if you're just looking for simple playback, but for more general purpose stuf including recording and signal manipulation, there are some advantages.
Just a note not really germane to previous discussions.
Had the opportunity to check out a bit of Windows compatibility recently, and I'm pretty impressed. An ASIO driver has been implemented for Wine that patches directly into a Jack graph, so you can run many asio-enabled Windows apps as part of your Linux system. I only tried AudioMulch, but apparently many non-trivial apps actually run.
This isn't terribley relevant if you're just looking for simple playback, but for more general purpose stuf including recording and signal manipulation, there are some advantages.
From the very start much of this thread has been way over my head -- and on top of that Klaus and others have been going quite extreme -- command line players, disabling video during playback etc etc. This is in keeping with the "diyaudio -- by the fanatics, for the fanatics" motto, but a bit extreme for me.
Anyway, the thread prompted me to help start off the wiki, and experiment with various Linux distros. A steep learning curve and a slippery slope -- as the net result is now that Ubuntu in various guises is what I use throughout my home. Edubuntu for the kids, Ubuntu for general home/office work, and a tweaked Ubuntu for audio. Overall, I slightly prefer Ubuntu to Windows XP, which after several years I had just gotten the hang of. Personally, I don't like Vista....
One experiment has been installing Ubuntu (7.10, 'out of the box' install), Vista and XP on identical office laptops and comparing audio playback (flac). On the windows laptops (foobar2000, Asio -> DDDac) I think vista was slightly better than XP. However, Ubuntu, out of the box, using ALSA, was clearly the best. After that, you can easily install the RT kernal, and it gets better still. And then there are a few of the tweaks from the wiki, which improve things again. In my system, Linux sounds better than Windows, now matter how much I tweaked XP. I find it to be not just a tweak kind of difference, but a positive component change kind of difference. I also found I nice friendly Linux audio player I can live with -- Quod Libet. Not as nice as J River Media Center I used most in windows, but I still get a simple cover art browser, and the app is light and fast.
The above is just to say that Soundcheck and Co. may seem a bit extreme for some, but I've found even a far far less ambitious Linux install has been highly worthwhile while still remaining user friendly. In terms of price it's free, though for newcomers there is a time-consuming learning curve. I found the Ubunti forums and the step-by-step guides on howtoforge.com invaluable.
just my 2 rupees. ;-)
Anyway, the thread prompted me to help start off the wiki, and experiment with various Linux distros. A steep learning curve and a slippery slope -- as the net result is now that Ubuntu in various guises is what I use throughout my home. Edubuntu for the kids, Ubuntu for general home/office work, and a tweaked Ubuntu for audio. Overall, I slightly prefer Ubuntu to Windows XP, which after several years I had just gotten the hang of. Personally, I don't like Vista....
One experiment has been installing Ubuntu (7.10, 'out of the box' install), Vista and XP on identical office laptops and comparing audio playback (flac). On the windows laptops (foobar2000, Asio -> DDDac) I think vista was slightly better than XP. However, Ubuntu, out of the box, using ALSA, was clearly the best. After that, you can easily install the RT kernal, and it gets better still. And then there are a few of the tweaks from the wiki, which improve things again. In my system, Linux sounds better than Windows, now matter how much I tweaked XP. I find it to be not just a tweak kind of difference, but a positive component change kind of difference. I also found I nice friendly Linux audio player I can live with -- Quod Libet. Not as nice as J River Media Center I used most in windows, but I still get a simple cover art browser, and the app is light and fast.
The above is just to say that Soundcheck and Co. may seem a bit extreme for some, but I've found even a far far less ambitious Linux install has been highly worthwhile while still remaining user friendly. In terms of price it's free, though for newcomers there is a time-consuming learning curve. I found the Ubunti forums and the step-by-step guides on howtoforge.com invaluable.
just my 2 rupees. ;-)
Thanks SSmith, for the encouragement 🙂
The truth is that, for non-initiated people, it is hard and intimidating.
Soundscheck's step by step wiki is very clear but last time I tried to configure a RAM disk though my X-Terminal, it refused to create it, even if it is supposed to have permanent privileges (or something like that). I thought: what the h**l! It sounds good enough un-tweaked...and led it go.
Apart, I use stock ripping and playing programs and I hear a silence between CD tracks that lasts less than a second and I' m too shy to ask for help
I think I'll have to find a local Linux guru that also loves music; I might even sell one of my USB DACs 😉
Cheers,
M
The truth is that, for non-initiated people, it is hard and intimidating.
Soundscheck's step by step wiki is very clear but last time I tried to configure a RAM disk though my X-Terminal, it refused to create it, even if it is supposed to have permanent privileges (or something like that). I thought: what the h**l! It sounds good enough un-tweaked...and led it go.
Apart, I use stock ripping and playing programs and I hear a silence between CD tracks that lasts less than a second and I' m too shy to ask for help
I think I'll have to find a local Linux guru that also loves music; I might even sell one of my USB DACs 😉
Cheers,
M
Hello Maxlorenz,
I use Linux for audio playback since just over a year. It has been frustrating for me many times and it still is occassionally. The strange thing is that when a problem is solved you can hardly remember why it was such a big problem.
I solve all my privilige issues by typing "sudo xterm" (in Ubuntu). The RAM disk is an improvement. I tried it with Foobar/Windows and XMMS/Linux and the difference is clear.
Kind regards,
Eddie
I use Linux for audio playback since just over a year. It has been frustrating for me many times and it still is occassionally. The strange thing is that when a problem is solved you can hardly remember why it was such a big problem.
I solve all my privilige issues by typing "sudo xterm" (in Ubuntu). The RAM disk is an improvement. I tried it with Foobar/Windows and XMMS/Linux and the difference is clear.
Kind regards,
Eddie
Dear Soundcheck,
I remember I read somewhere that you are using BruteFIR as the volume control and reported superior quality even when compared to the best available analog attenuater.
Can i ask you is that because of the 64bit floating point you use in BruteFIR? Does it matter if I use a 16 bit/44.1 file or 24 bit/96 file(upsampled)?
Did you change the volume by changing the gain setting in BruteFIR?
Thanks for you advice in advance
I remember I read somewhere that you are using BruteFIR as the volume control and reported superior quality even when compared to the best available analog attenuater.
Can i ask you is that because of the 64bit floating point you use in BruteFIR? Does it matter if I use a 16 bit/44.1 file or 24 bit/96 file(upsampled)?
Did you change the volume by changing the gain setting in BruteFIR?
Thanks for you advice in advance
soundcheck,
Thanks for your extensive investigations and reporting.
I have been experimenting with some of the methods you have explained.
My collection of CD's is currently being ripped to flac files, but I also want to be able to play an existing collection of MP3 and AAC files. Sure, these are not hifi.
So I thought that I would prefer ecasound over brutefir, since it handles flac, aac, and mp3 ... but after some experimentation I see that ecasound just uses the (separate) file conversion utilities flac, faad, and mpg123 to uncompress these filetypes as ecasound plays them.
So I guess, similarly, I could use these file conversion utilities and feed the uncompressed audio output to brutefir.
It's just a question of how to go about it.
Question 1. Is the sound quality using brutefir superior to ecasound?
Or is brutefir superior only in terms of its attenuation?
I consider it somewhat inconvenient to copy entire music files to tmpfs before playing them, so here is my "method 1" for playing flac files -
Of course, there are 2 applications running at the same time: flac and brutefir. I wonder how the Realtime kernel handles priority?
At the end of playback, the uncompressed flac file exists as "brutus.wav". Would it be ideal to write this file to tmpfs?
Here is my "method 2" for playing flac files, via standard input
First change the "input" section of /root/brutdefconf to -
device: "file" { path: "/dev/stdin"; };
then -
Of course, no file is created.
I would be interested in your comments about these methods.
Thanks for your extensive investigations and reporting.
I have been experimenting with some of the methods you have explained.
My collection of CD's is currently being ripped to flac files, but I also want to be able to play an existing collection of MP3 and AAC files. Sure, these are not hifi.
So I thought that I would prefer ecasound over brutefir, since it handles flac, aac, and mp3 ... but after some experimentation I see that ecasound just uses the (separate) file conversion utilities flac, faad, and mpg123 to uncompress these filetypes as ecasound plays them.
So I guess, similarly, I could use these file conversion utilities and feed the uncompressed audio output to brutefir.
It's just a question of how to go about it.
Question 1. Is the sound quality using brutefir superior to ecasound?
Or is brutefir superior only in terms of its attenuation?
I consider it somewhat inconvenient to copy entire music files to tmpfs before playing them, so here is my "method 1" for playing flac files -
Code:
flac -d test.flac -o brutus.wav | brutefir -nodefault /root/brutdefconfOf course, there are 2 applications running at the same time: flac and brutefir. I wonder how the Realtime kernel handles priority?
At the end of playback, the uncompressed flac file exists as "brutus.wav". Would it be ideal to write this file to tmpfs?
Here is my "method 2" for playing flac files, via standard input
First change the "input" section of /root/brutdefconf to -
device: "file" { path: "/dev/stdin"; };
then -
Code:
flac -d test.flac -c | brutefir -nodefault /root/brutdefconfOf course, no file is created.
I would be interested in your comments about these methods.
linuxfan said:
are u sure that would work? I would guess not. If you output to a file, you wouldn't get output to stdout.
You should either output to a temp file, play that uncompressed file and then remove it with something like this:
Code:
flac -d test.flac -o brutus.wav ; brutefir -nodefault /root/brutdefconf ; rm <brutus.wavor output directly to stdout and pipe it to brutefir as you've said.
linuxfan said:
brutefir sounds IMO better then ecasound.
You need to set rt-priorities by yourself. The feeding process must have higher priority then the receiving process.
You can try below:
chrt -f 50 flac .... | chrt -f 45 brutefir ....
brutefir has some kind of strange rt-prios hardcoded. You can see that if you start it. Somthing like 4 & 5. 5 for the filters and 4 for the output as far I remember. I changed them inside the code to higher values.
Great idea with the flac tool.
Write a small wrapper script which copies the files to /tmp and then play it, this way you don't have to copy the files manually:
flacbrut.bsh
------------
#!/bin/bash
for i in `find . -name "*.flac" -print` ; do
cp -f $i /tmp/test.flac
chrt -f 50 flac -d /tmp/test.flac -c | chrt -f 45 brutefir -nodefault /root/brutdefconf
done
exit 0
------------------------------
I assume that you start that script from the directory where your files are stored.
I havn't tested above.
Cheers
Hi folks.
I need to update the Wiki urgently. Quite some stuff has changed.
As usual Linux guys just spent time on hacking. Documenting things
properly are not really the strong side of many Linux folks. 😉
However.
I strongly recommend to try the tool Powertop ( root$ apt-get install powertop), which is developed by IBM. It'll show you quite some interesting things about power and processtime consuming processes and hardware.
I am down to approx. 12 wakeups per s. And a bit more then 10W power consumption before I start my audio playback. Usually you start with a couple of hundreds in an idle situation.
I'll post my settings in the Wiki soon.
Have a look at www.lesswatts.org. The good thing about the "Low-Power-Consumption" hype is that it improves my audioquality. 😉
Cheers
I need to update the Wiki urgently. Quite some stuff has changed.
As usual Linux guys just spent time on hacking. Documenting things
properly are not really the strong side of many Linux folks. 😉
However.
I strongly recommend to try the tool Powertop ( root$ apt-get install powertop), which is developed by IBM. It'll show you quite some interesting things about power and processtime consuming processes and hardware.
I am down to approx. 12 wakeups per s. And a bit more then 10W power consumption before I start my audio playback. Usually you start with a couple of hundreds in an idle situation.
I'll post my settings in the Wiki soon.
Have a look at www.lesswatts.org. The good thing about the "Low-Power-Consumption" hype is that it improves my audioquality. 😉
Cheers
Ripping under Linux - Rubyripper
Hi folks.
Until now Linux didn't really have a ripper I would trust.
Rubyripper is the first one I am using now. Before I was using
EAC and dbpoweramp. RR comes with rather limited features.
Still I think it's OK and reliable.
The read-out quality is achieved by reading out the track several times and comparing the respective checksums.
The advantage: You can rip with much higher drive speeds.
The developer is heavily working on an accourate-rip interface
to make things even more reliable.
Have a look here:
http://www.hydrogenaudio.org/forums/index.php?showtopic=60738
A small howto:
#Install dependencies and libs first:
sudo apt-get install subversion libgettext-ruby1.8 libgettext-ruby-util libglade2-ruby1.8 cd-discid libgtk2-ruby cdparanoia
$ cd /usr/src
#Checkout from svn:
$ sudo svn checkout http://rubyripper.googlecode.com/svn/trunk/ rubyripper
$ cd rubyripper
$ sudo ./configure --enable-gtk2 --enable-cli --prefix=/usr --bindir=/local/bin --locale=/share/locale \
--icondir=/share/icons/hicolor/128x128/apps --desktop=/share/applications
$ sudo make install
If everything runs OK you can start it:
$ rrip_gui
You also find an entry in the menu under Sound.
What you need to do though is to look up your drive offset from accourate-rip to get comparable results.
If it's not working
$ cd /usr/src/rubyrip*
$ sudo make clean
and try to fix it. Google will be your friend 😉
Deinstallation:
$ cd /usr/src/rubyrip*
$ sudo make uninstall
Have fun.
Cheers
Hi folks.
Until now Linux didn't really have a ripper I would trust.
Rubyripper is the first one I am using now. Before I was using
EAC and dbpoweramp. RR comes with rather limited features.
Still I think it's OK and reliable.
The read-out quality is achieved by reading out the track several times and comparing the respective checksums.
The advantage: You can rip with much higher drive speeds.
The developer is heavily working on an accourate-rip interface
to make things even more reliable.
Have a look here:
http://www.hydrogenaudio.org/forums/index.php?showtopic=60738
A small howto:
#Install dependencies and libs first:
sudo apt-get install subversion libgettext-ruby1.8 libgettext-ruby-util libglade2-ruby1.8 cd-discid libgtk2-ruby cdparanoia
$ cd /usr/src
#Checkout from svn:
$ sudo svn checkout http://rubyripper.googlecode.com/svn/trunk/ rubyripper
$ cd rubyripper
$ sudo ./configure --enable-gtk2 --enable-cli --prefix=/usr --bindir=/local/bin --locale=/share/locale \
--icondir=/share/icons/hicolor/128x128/apps --desktop=/share/applications
$ sudo make install
If everything runs OK you can start it:
$ rrip_gui
You also find an entry in the menu under Sound.
What you need to do though is to look up your drive offset from accourate-rip to get comparable results.
If it's not working
$ cd /usr/src/rubyrip*
$ sudo make clean
and try to fix it. Google will be your friend 😉
Deinstallation:
$ cd /usr/src/rubyrip*
$ sudo make uninstall
Have fun.
Cheers
soundcheck said:
well, before the new drives with the audio data cache "feature", cdparanoia was doing its job quite well.
Problem is, it have never been updated to cope with new (caching) drives, with which it is basically useless (it works, but as unreliably as any other ripper).
BTW, IME as long as you always get a smiley face and a clean progress bar (no '-', '+', '!', etc), it still give reliable results. Unfortunately, few CDs are so nice nowadays... 🙁
OK, but how does it do it? does it disable the drive cache?
If all it does is using cdparanoia (or cdda2wav) to do the real work (as I remember it doing at least in some earlier release), IMO/IME just repeating the extraction and verifying the checksums it's not so useful.
I have CDs which can be ripped out with cdparanoia on a given drive as many time as you like and they'll always produce the same result (identical wav files).
BUT, unfortunately, if you repeat the same on DIFFERENT DRIVEs, you'd get DIFFERENT RESULTs!
(and I mean different ALIGNED results - that is, after disregarding the different amount of silence that different drives may add at the beginning/end of each track).
As much as I hate windoze and closed-source software in general, I had to resort on using EAC (trough wine under Linux, of course!).
To me RR looks like a not so cool work-around to a problem which should be solved at a lover level - that is, updating/fixing the cdparanoia library. The sources are there... go get and hack them, please!
Linux memory player
Dear guys,
is it possible to prepare a script so that it can automatically just copy the wav files I ripped and stored in a CD to the Ram disc and than play from there?
Dear guys,
is it possible to prepare a script so that it can automatically just copy the wav files I ripped and stored in a CD to the Ram disc and than play from there?
Paolo.
Rubyripper builds on cdparanoia as a base and just adds some security features.
I wonder how much you can trust EAC under WIne!?!? Are all the
features it delivers, especially the low level hardware driver related ones, being made available by wine/Linux?
However.
I tried now for an hour to get EAC to work. It just doesn't start streaming data of the drive and hangs-up quite often.
It recognises the tracks, CDDB works, drive speed adjust works, but no data streaming. I need to spent more time on it as it seems.
Cheers
Klaus
Rubyripper builds on cdparanoia as a base and just adds some security features.
I wonder how much you can trust EAC under WIne!?!? Are all the
features it delivers, especially the low level hardware driver related ones, being made available by wine/Linux?
However.
I tried now for an hour to get EAC to work. It just doesn't start streaming data of the drive and hangs-up quite often.
It recognises the tracks, CDDB works, drive speed adjust works, but no data streaming. I need to spent more time on it as it seems.
Cheers
Klaus
Re: Linux memory player
of course, it's trivial. See the wiki.
why not? all EAC does (and can do) is sending (SCSI) commands to the drive using the standard protocol (ATAPI is just "SCSI-over-IDE"). Wine emulates the standard windows ASPI driver and doesn't get in the way.
mmmh... the only time I had a (possibly) similar problem with it I was trying to write to a shared FAT32 partition. Writing to a native ext3 file system it works just fine. Don't ask me why, that's really strange.
BTW: quick how-to to install and run EAC under wine:
0) I would suggest starting with a clean wine "system"...
(WARNING: that will remove wine setup and any previously installed program, including all of it's data if that was saved under the "C:" drive).
1) set up wine correctly! Start winecfg and go to the drive pane. Open the advanced settings. You must have the cdrom set-up as such (enter /dev/cdrom and select type cdrom). Save and exit.
You must get something like this (I have two cd/dvd drives):
Moreover, on the wine "registry", under the "[Software\\Wine\\Drives]" section, you must have:
If you have trouble getting this done right with winecfg, you may create the symbolic links as well as editing the system.reg manually (use your favorite text editor, it's a plain ascii file).
2) make sure no CD/DVD is in the drive(s)!
I don't know why, but if a disk is in the drive during setup and/or first run, you'll get an error, EAC will try to use a (non existing) "Installed external ASPI driver" and installation will get screwed. This is basically the only required trick.
3) download the official EAC .exe installer and start it using wine...
install as usual. You may want to include flac and "AccurateRip" too.
On the first run setup, under the EAC options make sure to select the "Native Win32 Interface for Win NT/2000/XP" and NOT the "Installed external ASPI driver".
Complete setting up the various option as usual, then exit EAC to make sure they'll get saved.
That's it. Start it again and enjoy!
I had no problem with it on both Debian "Etch" and (K)Ubuntu "Gutsy", in both case the 32bit version. Have not tried yet on 64bit systems.
ackcheng said:
of course, it's trivial. See the wiki.
soundcheck said:
why not? all EAC does (and can do) is sending (SCSI) commands to the drive using the standard protocol (ATAPI is just "SCSI-over-IDE"). Wine emulates the standard windows ASPI driver and doesn't get in the way.
mmmh... the only time I had a (possibly) similar problem with it I was trying to write to a shared FAT32 partition. Writing to a native ext3 file system it works just fine. Don't ask me why, that's really strange.
BTW: quick how-to to install and run EAC under wine:
0) I would suggest starting with a clean wine "system"...
Code:
rm -rf ~/.wine/(WARNING: that will remove wine setup and any previously installed program, including all of it's data if that was saved under the "C:" drive).
1) set up wine correctly! Start winecfg and go to the drive pane. Open the advanced settings. You must have the cdrom set-up as such (enter /dev/cdrom and select type cdrom). Save and exit.
You must get something like this (I have two cd/dvd drives):
Code:
$ ls -lAhF ~/.wine/dosdevices/
lrwxrwxrwx 1 paolo paolo 14 2007-04-27 16:49 a: -> /media/floppy0/
lrwxrwxrwx 1 paolo paolo 10 2007-12-29 01:39 c: -> ../drive_c/
lrwxrwxrwx 1 paolo paolo 13 2007-04-27 16:49 f: -> /media/cdrom0/
lrwxrwxrwx 1 paolo paolo 10 2007-12-29 01:16 f:: -> /dev/cdrom
lrwxrwxrwx 1 paolo paolo 13 2007-04-27 16:49 g: -> /media/cdrom1/
lrwxrwxrwx 1 paolo paolo 9 2007-12-29 01:16 g:: -> /dev/cdrwMoreover, on the wine "registry", under the "[Software\\Wine\\Drives]" section, you must have:
Code:
$ grep -i cdrom ~/.wine/system.reg
"F:"="cdrom"
"G:"="cdrom"If you have trouble getting this done right with winecfg, you may create the symbolic links as well as editing the system.reg manually (use your favorite text editor, it's a plain ascii file).
2) make sure no CD/DVD is in the drive(s)!
I don't know why, but if a disk is in the drive during setup and/or first run, you'll get an error, EAC will try to use a (non existing) "Installed external ASPI driver" and installation will get screwed. This is basically the only required trick.
3) download the official EAC .exe installer and start it using wine...
Code:
$ wine eac-whatever.exeinstall as usual. You may want to include flac and "AccurateRip" too.
On the first run setup, under the EAC options make sure to select the "Native Win32 Interface for Win NT/2000/XP" and NOT the "Installed external ASPI driver".
Complete setting up the various option as usual, then exit EAC to make sure they'll get saved.
That's it. Start it again and enjoy!
I had no problem with it on both Debian "Etch" and (K)Ubuntu "Gutsy", in both case the 32bit version. Have not tried yet on 64bit systems.
Paolo.
Figured it out. I had no problems to run it with a standard-kernel.
My tuned kernel had the SCSI-driver not activated.
I am not really sure though which one is needed. I just turned
quite some modules on.
We should add a Ripper Section to the Wiki. It's IMO quite an important
issue in terms of sound quality.
THX.
Cheers
Klaus
Figured it out. I had no problems to run it with a standard-kernel.
My tuned kernel had the SCSI-driver not activated.
I am not really sure though which one is needed. I just turned
quite some modules on.
We should add a Ripper Section to the Wiki. It's IMO quite an important
issue in terms of sound quality.
THX.
Cheers
Klaus
cdparanoia vs. EAC
A year ago I did a comparison of EAC under WinXP, original cdparanoia (debian testing), and cdparanoia with the readahead parameter raised 150 sectors to 1000 sectors, i.e. 2,3MB.
Specifications for my LG drive talk about 2MB of cache, no idea if that is used for audio too. EAC did not detect any cache. Each software ripped a partially scratched CD-DA 10 times.
EAC was configured using its wizard, secure mode, cache box unchecked.
The original cdparanoia produced different results from EAC: in 1 case 326 different bytes, in remaining 9 cases 320 bytes (always identical).
The modified cdparanoia 9 cases identical with EAC, 1 case difference of 4 bytes.
The modification was just changing p->readahead=150 in p_block.c.
A year ago I did a comparison of EAC under WinXP, original cdparanoia (debian testing), and cdparanoia with the readahead parameter raised 150 sectors to 1000 sectors, i.e. 2,3MB.
Specifications for my LG drive talk about 2MB of cache, no idea if that is used for audio too. EAC did not detect any cache. Each software ripped a partially scratched CD-DA 10 times.
EAC was configured using its wizard, secure mode, cache box unchecked.
The original cdparanoia produced different results from EAC: in 1 case 326 different bytes, in remaining 9 cases 320 bytes (always identical).
The modified cdparanoia 9 cases identical with EAC, 1 case difference of 4 bytes.
The modification was just changing p->readahead=150 in p_block.c.
- Status
- Not open for further replies.