phofman said:
Come on. Ugly hacks!?!? Have you ever had a look at it?
Rubyripper is using cdparanoia and added a multiple readout
on top. From a read-out quality perspective it is as good as EAC since quite some time.
As you mentioned cdparanioa was idling around for years with almost no maintenance or
evolution. This was a real mess.
The functionality which is coming with EAC, has IMO not been topped so far.
The closest application is dbpoweramp under Windows.
I really like the Accurate rip database feature . For quite a big number of CDs it is giving me 100% security that my rips are OK. (No idea if this has been implemented in one of the Linux applications yet)
Cheers
I was monitoring the discussion when rubyripper was being born. It is a clever but ugly hack to circumvent the cache deficiency of cdparanoia. I do not know if multiple reading using the same broken code can help, but rubyripper certainly pushed the linux ripping quality forward.
You are right, I did not think about Accurate, that is still missing.
You are right, I did not think about Accurate, that is still missing.
soundcheck said:
Ahem, sorry. Nowadays rubyripper may have a nice GUI and some handy features, but for what regards its original purpose it was and remains an ugly hack. The real solution would (and, eventually) have been to fix the bug in the paranoia code, not to try to circumvent it. Any such attempt is -by definition- a hack.
Moreover, sincerely I am not at all sure about the effectiveness of rubyripper in solving the problem (actually, I'm rather sure of the contrary. That is, that its re-reading strategies are mostly just a waste of time with little -if any- real usefulness).
I have tried similar workarounds manually long before rubyripper appeared. IME, at least with some drive/CD pairs, the old bugged cdparanoia was just repeating the same errors over and over again. You could repeat the extraction ad infinitum to no avail!
You could detect the errors (well, the inconsistencies: who knows which one is the right one?) only by re-extracting the same CD on another drive and/or using EAC.
BTW: AFAIK by default rubyripper passed the '-Z' (disable paranoia!) option to cdparanoia... so it could have used cdda2wav as well (or any other "insecure" DAE tool for that matter).
soundcheck said:
which kind of functionality are you speaking about?
AFAIK that's the only feature which is not available on native Linux software yet. But is it really useful? What does it really do, except disclosing your privacy?
BTW, I've read somewhere (here?
) that there is some Open Source code (both Perl and C) to handle the "AccurateRip" DB.If that's true, implementing "AccurateRip" check as a standalone Linux tool or including that feature in just about whatever DAE GUI or TUI should be trivial.
phofman said:
me too. And at least at the very beginning (I have not followed the discussion much further) IMHO the idea behind it was just about plain nonsense (see above). I don't know whether later on it got some more useful algorithm... if any can exists. 🙄
I increased the readahead parameter in the old cdparanoia code to exceed my drive's cache and surprisingly the hacked cdparanoia did produce the same results as EAC for a mildly scratched CD (unlike un-hacked cdparanoia, used in rubyripper). But that was not a real solution and I am glad the bug has been fixed properly.
Don't get me wrong guys.
I gave up on Linux ripping tools after one week of playing with them. 😉
I'll stay with EAC.
Cheers
I gave up on Linux ripping tools after one week of playing with them. 😉
I'll stay with EAC.
Cheers
Hi folks.
You might want to read this:
http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=40577
And than scroll 2 years back in this thread (no - better don't). 😉
And he is still using XMMS on an outdated non-rt kernel. 😀
Cheers:
You might want to read this:
http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=40577
And than scroll 2 years back in this thread (no - better don't). 😉
And he is still using XMMS on an outdated non-rt kernel. 😀
Cheers:
Do it the Unix way!
may I ask you why?
I have been forced to switch from cdparanoia to EAC (*) years ago when I discovered the cdparanoia cache bug. But now I plan to eventually go back to cdparanoia (well, not before doing some test on my own to make sure that the bug is really gone ).
What do you need more than just a simple:
???
If you prefer to keep a single file CD image instead, use something like:
or you can use cdparanoia without the "-B" flag to extract the CD image audio file and use "cdrdao read-toc" to get just the toc.
(then you can always convert the toc file to cue format using e.g. "cueconvert" from "cuetools" should you need that)
N.B.: since (at least on Debian Etch) the cdrdao binary seems to have libparanoia statically linked in, if you plan to use cdrdao to do the actual DAE you need to make sure that you get a cdrdao binary built using libparanoia >= 10.2.
Now you may want to encode the results with flac... what's easier than:
At the end you'd likely want to rename and/or tag the resulting flac file(s). To do so you can either use easytag to do it semi-automatically (using CDDB) with a GUI. Better yet, use cdrdao to get the CD toc file with CDDB info and, with a bit of scripting, do it fully automatically.
So what I would (and will) do is writing a simple script which will automatically extract audio & toc data with CDDB info as well as automatically tag & rename the resulting files. All without any manual intervention!
No GUIs, no TUIs, no interaction. Just a single, simple, customized script. All you'd have to do is inserting a CD and run the script. That's it. 😎
When it's done, eject the CD, insert the next one and start the script again... or you may include it in a loop, if you fill like recalling the last command again and again is annoying! 😀
Way much easier, quicker and overall better than any GUI/TUI DAE program... don't you think so?
This is the Unix (and Linux) way of doing things. And it is the RIGHT one. 😉
BTW: should you need any other processing (e.g. comparison of different extractions, joining and/or splitting audio files, etc), don't forget shntool!
That's the "Swiss army knife" of audio. No one here can live without it! 😉
(*) of course I ran EAC under Linux using WINE. As a fancy web icon said, "I don't do windows". 😀 I do not have any windoze machine - I simply don't use it for anything - and never did. In the early '90s I switched from plain old Dos (with the "4dos" CLI, remember? ) to AIX, Ultrix and other unixes (as well as VAX/VMS and OpenVMS). Then switched to GNU/Linux (almost exclusively) since '98. I guess my nick was not choosen by chance... 😀
soundcheck said:
may I ask you why?
I have been forced to switch from cdparanoia to EAC (*) years ago when I discovered the cdparanoia cache bug. But now I plan to eventually go back to cdparanoia (well, not before doing some test on my own to make sure that the bug is really gone
).What do you need more than just a simple:
Code:
cdparanoia -B -???
If you prefer to keep a single file CD image instead, use something like:
Code:
cdrdao read-cd --with-cddb --datafile mycd.bin mycd.tocor you can use cdparanoia without the "-B" flag to extract the CD image audio file and use "cdrdao read-toc" to get just the toc.
(then you can always convert the toc file to cue format using e.g. "cueconvert" from "cuetools" should you need that)
N.B.: since (at least on Debian Etch) the cdrdao binary seems to have libparanoia statically linked in, if you plan to use cdrdao to do the actual DAE you need to make sure that you get a cdrdao binary built using libparanoia >= 10.2.
Now you may want to encode the results with flac... what's easier than:
Code:
nice -5 flac --best --verify --delete-input-file *.wavAt the end you'd likely want to rename and/or tag the resulting flac file(s). To do so you can either use easytag to do it semi-automatically (using CDDB) with a GUI. Better yet, use cdrdao to get the CD toc file with CDDB info and, with a bit of scripting, do it fully automatically.
So what I would (and will) do is writing a simple script which will automatically extract audio & toc data with CDDB info as well as automatically tag & rename the resulting files. All without any manual intervention!
No GUIs, no TUIs, no interaction. Just a single, simple, customized script. All you'd have to do is inserting a CD and run the script. That's it. 😎
When it's done, eject the CD, insert the next one and start the script again... or you may include it in a loop, if you fill like recalling the last command again and again is annoying! 😀
Way much easier, quicker and overall better than any GUI/TUI DAE program... don't you think so?
This is the Unix (and Linux) way of doing things. And it is the RIGHT one. 😉
BTW: should you need any other processing (e.g. comparison of different extractions, joining and/or splitting audio files, etc), don't forget shntool!
That's the "Swiss army knife" of audio. No one here can live without it! 😉
(*) of course I ran EAC under Linux using WINE. As a fancy web icon said, "I don't do windows". 😀 I do not have any windoze machine - I simply don't use it for anything - and never did. In the early '90s I switched from plain old Dos (with the "4dos" CLI, remember?
) to AIX, Ultrix and other unixes (as well as VAX/VMS and OpenVMS). Then switched to GNU/Linux (almost exclusively) since '98. I guess my nick was not choosen by chance... 😀 Paolo.
THX for showing directions. 😉
I'll look it up.
Looks also like nice input to the Wiki.
Cheers
THX for showing directions. 😉
I'll look it up.
Looks also like nice input to the Wiki.
Cheers
Great instructions for WINE, thanks. I plan on trying it on the new release of Ubuntu Studio as soon as I make some (HD) space.
And, btw, these days we got a functional Linux for the Nintendo Wii console. I think it will be a great digital transport when someone finally develops a standard USB device driver for it.
It's spending only 18.4 W on peaks, and is also very quiet and tiny. Maybe we could power it from a big battery for some time along with nice NOS DAC and a ClassT flea amp.
Not to mention the coolness factor when you change the song with a short wiimote flick. Mmm... 😎
What do you say?
And, btw, these days we got a functional Linux for the Nintendo Wii console. I think it will be a great digital transport when someone finally develops a standard USB device driver for it.
It's spending only 18.4 W on peaks, and is also very quiet and tiny. Maybe we could power it from a big battery for some time along with nice NOS DAC and a ClassT flea amp.
Not to mention the coolness factor when you change the song with a short wiimote flick. Mmm... 😎
What do you say?
******* Thread jack, please excuse the interruption**********
xyrion-
Have more info on that Wii hack?
*******End of Thread jack, you may now return to your regularly scheduled discussion**********
😀
xyrion-
Have more info on that Wii hack?
*******End of Thread jack, you may now return to your regularly scheduled discussion**********
😀
24bit/192khz dac output form laptop
the best results i got sofar at the expense of a slightly large filesize was the use Ubuntu's Rhythmbow to rip the cd's directly into a 24 bit, 192khz FLAC ( lossless ) file ....
when played the output sounds sweet, defined, precise, and firm. at least in respect to the normal output ... and even better than my old heavely modded pioneer CD player, all this without any modification to hardware ( ohhhh how it might sound if tampered with 😱 )
the only thing that bug's my is that I would rather have the CD ripped into normal FLAC ( lossless 16bit/44.1khz ) and make the player output resampled 24bit/192khz directly to my onboard DAC .... that way i save space, at the expence of using processing power to convert every time i play it, well i just might drop it .... and get a bigger harddrive ?????
if any of you got an idea as to how Gstreamer/Alsa(.asoundrc)/Rhtyhmbox could be configured to do so, I'd appreciate any help to get me on the right path.
if i make it work I'll post how its done, so you guys/girls could do likewise to get full enjoyment of all that SWEET SWEET MUSIC
by the way Rhythmbox setting for high definition is to add or alter into this CD quality (lossless) FLAC ->depth=24,rate=192000,quality=8
and then rip your CDs *S*
Enjoy Folks
the best results i got sofar at the expense of a slightly large filesize was the use Ubuntu's Rhythmbow to rip the cd's directly into a 24 bit, 192khz FLAC ( lossless ) file ....
when played the output sounds sweet, defined, precise, and firm. at least in respect to the normal output ... and even better than my old heavely modded pioneer CD player, all this without any modification to hardware ( ohhhh how it might sound if tampered with 😱 )
the only thing that bug's my is that I would rather have the CD ripped into normal FLAC ( lossless 16bit/44.1khz ) and make the player output resampled 24bit/192khz directly to my onboard DAC .... that way i save space, at the expence of using processing power to convert every time i play it, well i just might drop it .... and get a bigger harddrive ?????
if any of you got an idea as to how Gstreamer/Alsa(.asoundrc)/Rhtyhmbox could be configured to do so, I'd appreciate any help to get me on the right path.
if i make it work I'll post how its done, so you guys/girls could do likewise to get full enjoyment of all that SWEET SWEET MUSIC
by the way Rhythmbox setting for high definition is to add or alter into this CD quality (lossless) FLAC ->depth=24,rate=192000,quality=8
and then rip your CDs *S*
Enjoy Folks
LaKrissen,
did you try upsampling to an integer multiple of the original frequency, i.e. to 176.4kHz? It should provide better results than the more complicated upsampling to a non-integer multiple.
You can configure the "rate" plug in your .asoundrc file, see http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html , http://www.hydrogenaudio.org/forums/lofiversion/index.php/t47591.html
did you try upsampling to an integer multiple of the original frequency, i.e. to 176.4kHz? It should provide better results than the more complicated upsampling to a non-integer multiple.
You can configure the "rate" plug in your .asoundrc file, see http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html , http://www.hydrogenaudio.org/forums/lofiversion/index.php/t47591.html
gainphile said:
You are right, now additional information can be recovered. However, modern DAC chips do an upconversion internally (usually 8x for 44.1/48kHz, 2x for 176.4/192kHz) to simplify the expensive analog filter behind the DAC stage. The three doubling upconversion stages are of no top quality. If you upsample in PC using quality algorithms (rabbit, rate in the new SoX), your DAC can circumvent their internal up-conversion stages.
Software upsampler probably does its job better than the one in his 192/24 DAC?gainphile said:
xyrion said:
I'd say so.
Unfortunately this ASRC stays usually in the loop, causing this or that extra problem
@ phofman: regarding "upsampling to a integer multiple"
You are right that this is better conversion, but if stuff is upsampled
to 192 at the DAC anyhow, you need to upsample to 192 on the PC.
There is no way around it.
One hint: I made quite some good experience by upsampling offline - converting
my files to the target format.
You folks should try it once.
Cheers
I also agree that offline sampling is excellent. There are software that cost a fraction compared to hardware version.
soundcheck said:
The upsampling we are talking about is not asynchronous SRC, as performed e.g. by SRC4192. It is a regular x2, x4, or x8 (or more) upsampling.
soundcheck said:
DAC chips do not upsample to 192kHz for 44.1-multiples frequencies, but to integer multiples, i.e. 176.4/352.8kHz. The upsampling ratio is set either by I2C bus, by (usually) two pins hooked to the soundcard chip's GPIOs (e.g. in Juli), or by other means (Intel HDA).
- Status
- Not open for further replies.