Page 1 of 1

Version 1.0b8 Observations

Posted: Mon May 25, 2009 3:33 am
by disneymike
Rip was crashing after every rip in version 1.0b7, but now does not exhibit that behavior. I also was getting audio files before which were not encoded properly. The file size and audio bit rate fields were blank and they would not load in iTunes or Peak Pro 6. This works fine in the current version.

In version 1.0b8, at the bottom of the main window, MB is mispelled as MIB.

It would be nice if the album window would rember its size and position between disc inserts. I find I have to enlarge it each time to see the entire disc contents.

What does the number in parentheses after the accuracy mean? Does a larger number indicate more confidence in the integrity of the rip? Does Rip use CD Paranoia for encoding like Max? Is the quality of the extracted audio better or the same as Max?

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 3:49 am
by sbooth
disneymike wrote:Rip was crashing after every rip in version 1.0b7, but now does not exhibit that behavior. I also was getting audio files before which were not encoded properly. The file size and audio bit rate fields were blank and they would not load in iTunes or Peak Pro 6. This works fine in the current version.
Great!
In version 1.0b8, at the bottom of the main window, MB is mispelled as MIB.
Actually, it's not a misspelling. See http://en.wikipedia.org/wiki/Gigabyte
It would be nice if the album window would rember its size and position between disc inserts. I find I have to enlarge it each time to see the entire disc contents.
The current behavior is that each individual album window remembers its own position. Do you think it would be more useful for all album windows to have the same position?
What does the number in parentheses after the accuracy mean? Does a larger number indicate more confidence in the integrity of the rip? Does Rip use CD Paranoia for encoding like Max? Is the quality of the extracted audio better or the same as Max?
The number in parens is the number of matches in AccurateRip- basically the number of other users whose extracted audio matches what you just got.

Rip does not use cdparanoia, but an engine designed by me.

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 4:06 am
by disneymike
Thanks for the clarification concerning MiB. I was not aware of that and stand corrected. :)

For me, yes, the album window being the same for all albums would be helpful.

Does your custom engine produce files of equal quality to the ones produced by cdparanoia? I ask this because I want to extract the best copy of my CD's audio possible.

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 4:10 am
by sbooth
disneymike wrote:Does your custom engine produce files of equal quality to the ones produced by cdparanoia? I ask this because I want to extract the best copy of my CD's audio possible.
I suppose that only time will tell, but on a good drive that supports C2 (which is almost anything included on a recent Apple system) you should get the same results. On a drive with shoddy C2 support, there is a chance for errors to slip through unnoticed if the disc is not in the AccurateRip database. Regardless of the drive used, you should feel comfortable about a rip if the AccurateRip value is more than 1.

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 4:17 am
by disneymike
Am I right to asume if AccurateRip is not employed and Rip simply verifies the track, it should be of the same integrity, but we just don't know for sure because we're not comparing it other individual's rips of the same material? In other words, an AccurateRip value of more than 1 doesn't mean a better ripping algorithm was used, it just helps to verify we're getting the same thing as others.

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 4:27 am
by disneymike
One other thing I've noticed with 1.0b8. Every once in a while I get a "Calculating AccurateRip offsets" messagen and the ripping process appears to hang. It does seem to be reproducible. If I rip again using the same CD, it seems to encounter the same problem on the same track. Is there a workaround for this?

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 5:08 am
by sbooth
The same extraction algorithm is used whether or not AccurateRip is used. There is a shortcut with AR- if the track checksum matches then further verification is not performed.

As far as the hang, are there any messages printed to the Console? Can you provide details on the disc and track?

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 5:14 am
by disneymike
I'll let you know the next time I have a hang. I didn't take note of which disc and track in the past. How do you check for messages printed to the console?

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 5:32 am
by sbooth
In the Applications/Utilities folder in an application called Console. When you run it you will see messages sent to the console, stderr, etc. Look for anything prefaced with Rip.

Re: Version 1.0b8 Observations

Posted: Mon May 25, 2009 6:57 am
by disneymike
This is a different behavior, but on my Frankie Valli and the Four Seasons Anthology disc, track 25 does not complete. It rescans a series of 3 or 4 sector ranges over and over.

Here is the info from the console:

recording code (ISRC) for track 1
[2009-05-24 23:29:13 -0700] Unable to read the international standard recording code (ISRC) for track 2
[2009-05-24 23:29:30 -0700] Unable to read the international standard recording code (ISRC) for track 3
[2009-05-24 23:29:45 -0700] Unable to read the international standard recording code (ISRC) for track 4
[2009-05-24 23:30:02 -0700] Unable to read the international standard recording code (ISRC) for track 5
[2009-05-24 23:30:18 -0700] Unable to read the international standard recording code (ISRC) for track 6
[2009-05-24 23:30:34 -0700] Unable to read the international standard recording code (ISRC) for track 7
[2009-05-24 23:30:46 -0700] Unable to read the international standard recording code (ISRC) for track 8
[2009-05-24 23:31:02 -0700] Unable to read the international standard recording code (ISRC) for track 9
[2009-05-24 23:31:18 -0700] Unable to read the international standard recording code (ISRC) for track 10
[2009-05-24 23:31:35 -0700] Unable to read the international standard recording code (ISRC) for track 11
[2009-05-24 23:31:48 -0700] Unable to read the international standard recording code (ISRC) for track 12
[2009-05-24 23:32:02 -0700] Unable to read the international standard recording code (ISRC) for track 13
[2009-05-24 23:32:14 -0700] Unable to read the international standard recording code (ISRC) for track 14
[2009-05-24 23:32:28 -0700] Unable to read the international standard recording code (ISRC) for track 15
[2009-05-24 23:32:43 -0700] Unable to read the international standard recording code (ISRC) for track 16
[2009-05-24 23:32:56 -0700] Unable to read the international standard recording code (ISRC) for track 17
[2009-05-24 23:33:09 -0700] Unable to read the international standard recording code (ISRC) for track 18
[2009-05-24 23:33:20 -0700] Unable to read the international standard recording code (ISRC) for track 19
[2009-05-24 23:33:35 -0700] Unable to read the international standard recording code (ISRC) for track 20
[2009-05-24 23:33:45 -0700] Unable to read the international standard recording code (ISRC) for track 21
[2009-05-24 23:33:57 -0700] Unable to read the international standard recording code (ISRC) for track 22
[2009-05-24 23:34:10 -0700] Unable to read the international standard recording code (ISRC) for track 23
[2009-05-24 23:34:20 -0700] Unable to read the international standard recording code (ISRC) for track 24
[2009-05-24 23:34:33 -0700] Unable to read the international standard recording code (ISRC) for track 25
[2009-05-24 23:38:14 -0700] Track has no errors

Update: I tried the disc again and it completed without incident, so it appears this problem is not reproducible.