Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Improving cdparanoia (Read 10702 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Improving cdparanoia

Hi there!

Cdparanoias active development stopped in 2001 while EAC is still closed source and only available on Windows.
I think, it's time to give the users of Mac OS X and Linux also a decent DAE tool. I've read several complaints about cdparanoia spread about several places on the internet. But I found no place, where people willing to improve cdparanoia come together. So I started this thread.

How can you help?

- Give ideas what must be improved.
- Test new features. maybe developed in the near future
- Implement new features


My first idea is to write a tool capable of testing wether a drive uses an audio cache. My idea is to extract an ascending number of bytes while measuring the exctraction speed. If the drives caches, there should be a break-in of extraction speed at a particular number of bytes. Then, you have a hint how big the cache may be.

The appropriate programming language is C, because you have to access OS APIs, which are desigend for C (for example "cdrom.h" on Linux).

Improving cdparanoia

Reply #1 –
A better CD-Paranoia would even help windows users.  You can use EACs extraction routines in your own program,  but you have to pay and it only comes as a DLL.  An open source EAC quality ripper library would be nice.

In particular i'd look forward to a program that does everything EAC does, but with a better UI, and is kept up to date more often.  I think EAC is a one man show, if i'm not mistaken.

Improving cdparanoia

Reply #2 –
I'm not sure what CD-paranoia lacks but here are some things that EAC does have:

Hidden sector synchronization (jitter correction)
Read error and complete loss of sync detection and correction
Automatic Speed reduction on errors and fallback afterwards
Detection of pre-track gaps
Detection of silence in pre-track gaps
Output of time positions of all non-exact corrections and listen to these positions
Overreading capability for extracting correctly with non-zero offsets
CRC checksum calculation for tracks

Improving cdparanoia

Reply #3 –
Quote
- A GTK2 front end with cddb integration. (If Linux will persuade us to abandon M$, everything must be GUI based)
Quote


This has existed for a long time. The program is called Grip. There's also Goobox, Kaudiocdcreator(QT/KDE-prog) and many more.

Improving cdparanoia

Reply #4 –
Hi!

Great idea. I think it would be better to make a whole new program.

Quote
My first idea is to write a tool capable of testing wether a drive uses an audio cache. My idea is to extract an ascending number of bytes while measuring the exctraction speed. If the drives caches, there should be a break-in of extraction speed at a particular number of bytes. Then, you have a hint how big the cache may be.

The appropriate programming language is C, because you have to access OS APIs, which are desigend for C (for example "cdrom.h" on Linux).


Agreed. Doing things in C would also attract more developers to add and fix things.

Quote
I would like

- Secure ripping comparable to EAC with cache flush
- Test and copy with CRC check
- A GTK2 front end with cddb integration. (If Linux will persuade us to abandon M$, everything must be GUI based)


Definitely needs to be secure. I'd rather a command line tool, though. That way it doesn't depend on KDE/Gnome/console at all. CDDB can be integrated in the frontends. How about writing the program in a way that ripper frontends like abcde, grip etc. just can change the name of the executable? Win-Win situation. Gives their respective developers time to add new features to their application (test and copy for instance).

Quote
I'm not sure what CD-paranoia lacks but here are some things that EAC does have:

Hidden sector synchronization (jitter correction)
Read error and complete loss of sync detection and correction
Automatic Speed reduction on errors and fallback afterwards
Detection of pre-track gaps
Detection of silence in pre-track gaps
Output of time positions of all non-exact corrections and listen to these positions
Overreading capability for extracting correctly with non-zero offsets
CRC checksum calculation for tracks


The need may arise to bug some kernel developers about the speed reduction issue. But I think it'd be worth it. Definitely.

I'd like to add offset correction (prolly not named before because cdparanoia already can do that) and C2 error awareness which can speed up the ripping.

I think the toughest nut may be that cdparanoia was written with ide-scsi emulation in mind. I think using ide-scsi emulation for DAE makes things a lot easier. But as linux pretty much moves away from ide-scsi emulation with high velocity I think there's no way around a program which uses pure IDE access (maybe we need to bug the kernel devs some more... ).


Cheers

mic

Improving cdparanoia

Reply #5 –
Secure ripping like EAC with the ability to disable the drives caching/C2.
Read offset correction (and overreading ability).
Cuesheet generation.
Ripping track 1 pregaps as seperate files (not sure if you can do this already with cdparrnoia, but EAC needs tooptionally be able to.)
Log files.
Test & Copy function with a CRC check.
A proper UI (although not necassary)
A Windows port (why not have an alternative to EAC on windows?)

With those features it would surpass EAC I think.  Can't beat open source.

Improving cdparanoia

Reply #6 –
The majority of CD ripping GUI's for linux use cdparanoia as a backend (grip and kaudiocreator being the most common IMO).  Just improve cdparanoia itself, and nearly every ripper for linux will be improved.

Improving cdparanoia

Reply #7 –
Quote
The majority of CD ripping GUI's for linux use cdparanoia as a backend (grip and kaudiocreator being the most common IMO).  Just improve cdparanoia itself, and nearly every ripper for linux will be improved.
[a href="index.php?act=findpost&pid=340533"][{POST_SNAPBACK}][/a]


Question is if it easier and faster to improve cdparanoia than to build a new app from scratch. I mean it usually takes more time to understand code than to write it. If there were only small changes to cdparanoia necessary then of course I'd just add to cdparanoia. But maybe it'll amount to more than a few minor changes.

Cheers

mic

Improving cdparanoia

Reply #8 –
Quote
- A GTK2 front end with cddb integration. (If Linux will persuade us to abandon M$, everything must be GUI based)

A frontend with freeDB and codepages integration would be perfect. No frontend I have seen so far has any codepage converting ability on freeDB results. It is one of the numerous reasons which make me use EAC+foobar.
[edit]When I say "frontend", it could also be a command line frontend, such as Abcde, or an easily scriptable program.
Stupidity is root of all evil.

Improving cdparanoia

Reply #9 –
perhaps a library + frontend - so other programs (read GUIs) can utilize this how they see fit.

Improving cdparanoia

Reply #10 –
Quote
Question is if it easier and faster to improve cdparanoia than to build a new app from scratch. I mean it usually takes more time to understand code than to write it. If there were only small changes to cdparanoia necessary then of course I'd just add to cdparanoia. But maybe it'll amount to more than a few minor changes.

Cheers

mic
[{POST_SNAPBACK}][/a]


Cdparanoia is not a big project. It was maintained and improved mainly by one person only. You can look through the code and understand it in a single day. (That's another reason, why I'm wondering that nobody is improving it!?)
Joel hast written a goot article about throwing code away and start from the scratch: [a href="http://www.joelonsoftware.com/articles/fog0000000069.html]http://www.joelonsoftware.com/articles/fog0000000069.html[/url]

I think, the first step is not to improve cdparanoia, but to find out how the special techniques of EAC actually WORK. For example, there's no documentation how the cache detection actually work!
So I'm writing an experimental tool, that's only purpose is to determine a cache. I will hopefully post it the next days.

Improving cdparanoia

Reply #11 –
An idea to improve cdparanoia (and I really don't know if it is possible).

1. Find out how much cache the drive has, keep it as something like cachesize.
2. Make a block size to be as big as the number of samples needed to fill "cachesize".
2. Read the i th block of samples, (made of blocksize samples).
3. Read the i+1 th block.
4. Repeat 2 and 3 until there are no more errors to correct on blocks i and i+1
5. i = i +2, and repeat the process.

Perhaps it is some overkill, but that's the naive approach I would take to solve the cache problem by filling it again with samples that you actually need to read to correct errors. No need for ugly flushing

Of course, I don't know if it is possible to query the OS or the drive to know how much cache it has.

I don't have time right now to find out how to implement nor to implement it, but if anyone gives it a try lemme know if it worked

Improving cdparanoia

Reply #12 –
Quote
I think, the first step is not to improve cdparanoia, but to find out how the special techniques of EAC actually WORK. For example, there's no documentation how the cache detection actually work!

Why would you care about that ? From all the silly things
in EAC, the cache detection is one of the most well known,
and it still regularly reports different results from Feurio.
As usual Andre made up something completely on his
own - in this case a 3 steps method which does not even
look for a speed break on cache(-line) boundary - and of
course it does not work. Do it your way instead of trying
to imitate a buggy piece of software.

Improving cdparanoia

Reply #13 –
Quote
An idea to improve cdparanoia (and I really don't know if it is possible).

1. Find out how much cache the drive has, keep it as something like cachesize.
2. Make a block size to be as big as the number of samples needed to fill "cachesize".
2. Read the i th block of samples, (made of blocksize samples).
3. Read the i+1 th block.
4. Repeat 2 and 3 until there are no more errors to correct on blocks i and i+1
5. i = i +2, and repeat the process.

If block i is ok and block i+1 contains an error, you will keep on reading
block i just to flush that cache, which is useless. Cache flushing obviously
has to be a positive side effect of a useful read access, and this is what
existing tools already do.

Improving cdparanoia

Reply #14 –
Quote
Quote
An idea to improve cdparanoia (and I really don't know if it is possible).

1. Find out how much cache the drive has, keep it as something like cachesize.
2. Make a block size to be as big as the number of samples needed to fill "cachesize".
2. Read the i th block of samples, (made of blocksize samples).
3. Read the i+1 th block.
4. Repeat 2 and 3 until there are no more errors to correct on blocks i and i+1
5. i = i +2, and repeat the process.

If block i is ok and block i+1 contains an error, you will keep on reading
block i just to flush that cache, which is useless. Cache flushing obviously
has to be a positive side effect of a useful read access, and this is what
existing tools already do.
[a href="index.php?act=findpost&pid=341294"][{POST_SNAPBACK}][/a]



Ohh really, and what are those tools for LINUX?

As for the algorithm, if block i is ok and block i+1 contains an error then just start readig block i+2 instead of block i. Jeez.

Improving cdparanoia

Reply #15 –
Quote
Ohh really, and what are those tools for LINUX?

Uh, where did I mention linux ? You said "i have an idea" and I said that
this idea is already implemented (in a better way) in some tools. No need to
reinvent the wheel, especially a broken one.

Quote
As for the algorithm, if block i is ok and block i+1 contains an error then just start readig block i+2 instead of block i. Jeez.

And then what do you do if i+2 has an error too ? You chose to post an algorithm,
I just pointed out why it's unefficient : if you can't take critics, don't post such things
on a public board.

Improving cdparanoia

Reply #16 –
Quote
Uh, where did I mention linux ? You said "i have an idea" and I said that
this idea is already implemented (in a better way) in some tools. No need to
reinvent the wheel, especially a broken one.


Quote
Cdparanoias active development stopped in 2001 while EAC is still closed source and only available on Windows.
I think, it's time to give the users of Mac OS X and Linux also a decent DAE tool. I've read several complaints about cdparanoia spread about several places on the internet. But I found no place, where people willing to improve cdparanoia come together. So I started this thread.



Quote
And then what do you do if i+2 has an error too ? You chose to post an algorithm,
I just pointed out why it's unefficient : if you can't take critics, don't post such things
on a public board.
[a href="index.php?act=findpost&pid=341563"][{POST_SNAPBACK}][/a]


If you are reading i+1 and i+2 and both have errors then you just keep reading them the way I described, I thought that was common sense. If all of the sudden you corrected all of the errors in i+2 then start reading i+3 instead of i+2 and keep correcting the errors in i+1. You flush the cache of the drive by reading blocks of data you actually need.

Until someone comes up with a way to flush the cache under linux, workarounds are a must.

Improving cdparanoia

Reply #17 –
Quote
Quote
Cdparanoias active development stopped in 2001 while EAC is still closed source and only available on Windows.


You don't seem to get the point, nevermind.

Quote
If you are reading i+1 and i+2 and both have errors then you just keep reading them the way I described, I thought that was common sense. If all of the sudden you corrected all of the errors in i+2 then start reading i+3 instead of i+2 and keep correcting the errors in i+1.

Finally. Now put it all together and you can propose a real algorithm.

Quote
Until someone comes up with a way to flush the cache under linux, workarounds
are a must.

Blah. There's only one way to explicitely flush the cache - via the FUA bit - and
this works indifferently under linux or windows, like any MMC command. And as
I mentioned here a few years ago, cdparanoia already contains code related to
the FUA bit, it just needs a small change to actually work.

Improving cdparanoia

Reply #18 –
Quote
This has existed for a long time. The program is called Grip. There's also Goobox, Kaudiocdcreator(QT/KDE-prog) and many more.


Yes I added Grip to the wiki and K3B also.  If that's one that the wiki lacks it's applications for OS X and POSIX users.


Quote
So I'm writing an experimental tool, that's only purpose is to determine a cache. I will hopefully post it the next days.


Cache detection? interesting.

Quote
Uh, where did I mention linux ? You said "i have an idea" and I said that
this idea is already implemented (in a better way) in some tools. No need to
reinvent the wheel, especially a broken one.


He was just trying to come up with the brute force method off the top of his head, there nothing wrong with this. It sounds logical to me and I am not much of an expert in DAE. 

Quote
this works indifferently under linux or windows, like any MMC command. And as
I mentioned here a few years ago, cdparanoia already contains code related to
the FUA bit, it just needs a small change to actually work.


Do you KNOW of any changes that you can write into the algorithm to make it work then?  . You aren't really helping the situation besides critisizing him in a useful way. I am interested in a learning a little about this seeing that I know how to code a little, but I never understood what the actual problem with cdparanoia was either (just that people who use EAC always complain about it, because their rip is not "perfect" down to the smallest degree of anal accuracy).
budding I.T professional

Improving cdparanoia

Reply #19 –
Quote
(just that people who use EAC always complain about it, because their rip is not "perfect" down to the smallest degree of anal accuracy).
[a href="index.php?act=findpost&pid=341628"][{POST_SNAPBACK}][/a]


This is mainly due to offset. Something most of us who know it doesn't matter so much, don't care about.

Improving cdparanoia

Reply #20 –
Quote
Quote
(just that people who use EAC always complain about it, because their rip is not "perfect" down to the smallest degree of anal accuracy).
[a href="index.php?act=findpost&pid=341628"][{POST_SNAPBACK}][/a]


This is mainly due to offset. Something most of us who know it doesn't matter so much, don't care about.
[a href="index.php?act=findpost&pid=341653"][{POST_SNAPBACK}][/a]

Not to make an argument, but without offset correction I wouldn't touch another ripper than EAC.  If your going to try to make secure accurate ripping, do it right or not at all.  There are loads of non-secure rippers out there for such uses.  EAC was written for people wanting perfect rips.  At this point cdparanoia's only area's for real improvement would be adding features like offset correction and other EAC exclusive features.  EAC isn't perfect, but it's the closest thing to it at this point in time.  If couldn't make "perfect" rips I may as well just use mp3 or ogg for my music.  Transparent enough for most uses.  I think it would be great for the linux community to have a proper secure (and open source) ripper.  If knew how to program I'd have attempted to do so already.

Improving cdparanoia

Reply #21 –
Quote
This is mainly due to offset. Something most of us who know it doesn't matter so much, don't care about.


Thank you for enlightening me .  It was never something I looked into.


Quote
EAC isn't perfect, but it's the closest thing to it at this point in time. If couldn't make "perfect" rips I may as well just use mp3 or ogg for my music. Transparent enough for most uses. I think it would be great for the linux community to have a proper secure (and open source) ripper.


I guess that would completely make sense, I am not disagreeing with you  . It was never something that bothered me that much though, despite the fact I do use cdparanoia and am interested it's setbacks.  I guess it makes some folks sleep easier at night though knowing that they have a secure rip.  . I am just not that hardcore even though I am on certain things.
budding I.T professional

Improving cdparanoia

Reply #22 –
Quote
I'd like to add offset correction (prolly not named before because cdparanoia already can do that)[a href="index.php?act=findpost&pid=340521"][{POST_SNAPBACK}][/a]

Correct. cdparanoia already has offset correction support.

Improving cdparanoia

Reply #23 –
Quote
Do you KNOW of any changes that you can write into the algorithm to make it work then?  . You aren't really helping the situation besides critisizing him in a useful way.

Sure, but for me there's not much point in discussing technical details right now.
This is not the first thread about improving cdparanoia or xyz open source tool,
and in the end the problem is always to find people with enough time and
commitment to maintain a new code tree. The day I see a new cdparanoia
release I'll consider helping.