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).

Lack of really good audio software is what prevents me coming to Linux (that and DVD Shrink).

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)

it is more like the lack of foobar2000 that holds people back.

for most people, xmms+k3b would replace foobar+EAC.

and for those that are more adventurous, they may look to players like lamip or quodlibet.

dvdshrink works 100% in wine

also, check out k9copy (vamps frontend) and kdvdbackup for native linux apps that do DVD9>DVD5 backups.

however, linux is missing a great mpeg2 encoder like CCE, (or none that i am aware of.)


later
(btw, i just added k9copy and vamps to RW/Debian last week)

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.

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

I use foobar2k with columns UI, and xmms could never replace the foobar goodness. There are literally too many features to list that xmms doesn't have. I couldn't leave M$ without foobar.

Most casual users use winamp anyway, so xmms would be a home from home for them.



However lamip looks very promising. I think it could become the foobar for linux. Does it have apev2 masstagging support?



Cool

I have a spare machine lying around, I will try lamip and dvdshrink on Ubuntu soon.

[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.

Hi!

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



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



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).



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

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.

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.

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

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.

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

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: http://www.joelonsoftware.com/articles/fog0000000069.html

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.

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

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.

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.

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.

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.


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.

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.

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


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


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.

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.




Cache detection? interesting.



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.



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).

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

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.

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




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.

Correct. cdparanoia already has offset correction support.

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.