IPB

Welcome Guest ( Log In | Register )

104 Pages V  « < 70 71 72 73 74 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
lipidicman
post Feb 17 2012, 19:46
Post #1776





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



Thanks again Korth. I'm only up to page 9 so far! Trying to take it all in rather than skim.

As I understand it, by doing at least 2 passes it is already doing test and copy. The log file shows both CRCs anyway.
Go to the top of the page
+Quote Post
lipidicman
post Feb 18 2012, 08:48
Post #1777





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (korth @ Feb 17 2012, 18:36) *
QUOTE (lipidicman @ Feb 17 2012, 17:29) *
With EAC I found this drive can overread. Perhaps I made a mistake, or does CueRipper always set this to 'No'?
Similar question asked and answered. I have a Plextor CDR capable of Overread into Lead-In and Lead-Out. Also No in CUERipper.
More testing of Cueripper.

When I compare against EAC (with overread) some CDs have identical test CRC32 for the last track. This will be because CueRipper is filling up the offset with zeroes, and the missed part contained zeros anyway. My offset is +30. Other CDs do appear to have data to the end.

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

I suppose it might even be a good feature here for those people correcting offsets if you could check that you are only moving zeroes around (although I understand that correcting offsets has no real benefits, I only enter the offset in the main window to alter the offset for a verify to get the ARv2 result if it wasn't corrected properly at rip)
Go to the top of the page
+Quote Post
mjb2006
post Feb 18 2012, 09:54
Post #1778





Group: Members
Posts: 848
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (lipidicman @ Feb 18 2012, 00:48) *
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)
Go to the top of the page
+Quote Post
lipidicman
post Feb 18 2012, 19:42
Post #1779





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (mjb2006 @ Feb 18 2012, 09:54) *
QUOTE (lipidicman @ Feb 18 2012, 00:48) *
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?
mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)
Clever, but I wasn't thinking straight this morning. "Fill up missing offset samples with silence : Yes" will stop me from testing this way.

I'm testing CueRipper results against EAC. EAC overreads into the lead out with my PLEXTOR DVDR PX-716A (+30 offset)

Am I just being picky wanting my last track CRC32 to match what I get when I run EAC test in burst mode? It usually does because the last 30 samples are usually digital silence.

I'm just regarding the CRC32 as being superior to the (flawed) AR CRC (and even the v2 has flaws right?). Isn't this why Gregory uses CRC32? Am I wrong here?

Coming soon: How I Learned to Stop Worrying and Love the Rip rolleyes.gif
Go to the top of the page
+Quote Post
korth
post Feb 18 2012, 20:20
Post #1780





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



I thought you already figured out that a few leading and trailing samples were removed from the CTDB CRC because drives with different offsets and no overread capability will produce different data in those areas. The link points to a discussion about the localDB but the two are similar.
AR CRCs are also calculated with a few leading samples from the first track and a few trailing samples from the last track removed.
I guess I don't have the same obsession for a possible 30 samples (0.00068 seconds) of inaudible digital noise at the end of the disc if the rest of the disc verifies.

This post has been edited by korth: Feb 18 2012, 21:09


--------------------
korth
Go to the top of the page
+Quote Post
lipidicman
post Feb 18 2012, 21:24
Post #1781





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



Yes, I know about how AR and CTDB drop the start and end (5 and 10 sectors). I'm not really worried about those last few samples in my rips. What I am doing is testing my CueRipper rips against EAC results. The only way I have to do this is to use the full CRC32 from the EAC log. As I understand it CRC is less robust (hence why Gregory uses CRC32), and ARv1 is further flawed (hence ARv2).

I guess I'm trying to check if I have one of these errors in EAC, or drive bugs, that I keep hearing about. Greynol might be able to point me in the right direction here. I figured that using two drives and two bits of software would flush any problems out.

It's the scientific training.....just a few more checks and then I'll be happy rolleyes.gif

I do think that checking for digital silence could be implemented when people are correcting offsets in CueTools. I know it has no real benefit to correct the offset and the downside is losing more samples. But if you check for zeroes, then the downside vanishes.
Go to the top of the page
+Quote Post
lipidicman
post Feb 18 2012, 23:26
Post #1782





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



Just finished ripping 80 cds to discover:

Used drive : PLEXTOR DVDR PX-716A Adapter: 1 ID: 0
Gap handling: Not detected, thus appended to previous track

sad.gif

Now, I understand that this does not affect the FLACs, but means my cuesheet will have no Index 00. Other than the negative numbers on a burnt CD there are no bad consequences are there? I read this guide to gaps years ago

I do think the program should warn if it fails gap detection

A couple of other issues.
1) I had a problem where unique didn't work (may have been my fault as I had manually renamed the directory to remove an extraneous 'disc1') and the program simply overwrote the files without asking. Is this the expected behaviour?
2) I'm trying my other drive in the light of the gap detection. I see a changed CTDB confidence. Should I get this increase as a result of my own re-rip? Is it the change of drive?

This post has been edited by lipidicman: Feb 19 2012, 00:10
Go to the top of the page
+Quote Post
lipidicman
post Feb 20 2012, 10:21
Post #1783





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (lipidicman @ Feb 18 2012, 23:26) *
Just finished ripping 80 cds to discover:

Used drive : PLEXTOR DVDR PX-716A Adapter: 1 ID: 0
Gap handling: Not detected, thus appended to previous track
Strange, this is not consistent. Out of 80 cds, 4 were not detected (consistently, with several retries) although one has just had the gaps detected where they weren't before.

This may not be CueRipper though. I think I recall problems with EAC, although my recollection is that EAC would hang during detection. This was a long time ago though, so I could be wrong.
Go to the top of the page
+Quote Post
Goratrix
post Feb 20 2012, 12:25
Post #1784





Group: Members
Posts: 131
Joined: 5-August 08
Member No.: 56722



QUOTE (lipidicman @ Feb 19 2012, 00:26) *
Other than the negative numbers on a burnt CD there are no bad consequences are there?


This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
Go to the top of the page
+Quote Post
lipidicman
post Feb 20 2012, 13:17
Post #1785





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (Goratrix @ Feb 20 2012, 12:25) *
QUOTE (lipidicman @ Feb 19 2012, 00:26) *
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful. Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.
Go to the top of the page
+Quote Post
Goratrix
post Feb 20 2012, 13:42
Post #1786





Group: Members
Posts: 131
Joined: 5-August 08
Member No.: 56722



QUOTE (lipidicman @ Feb 20 2012, 14:17) *
QUOTE (Goratrix @ Feb 20 2012, 12:25) *
QUOTE (lipidicman @ Feb 19 2012, 00:26) *
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful. Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.


HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.
Go to the top of the page
+Quote Post
lipidicman
post Feb 20 2012, 14:29
Post #1787





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (Goratrix @ Feb 20 2012, 13:42) *
HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.
Yes, of course I agree.
Go to the top of the page
+Quote Post
korth
post Feb 20 2012, 15:54
Post #1788





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



QUOTE (lipidicman @ Feb 18 2012, 23:26) *
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [link]


--------------------
korth
Go to the top of the page
+Quote Post
lipidicman
post Feb 20 2012, 16:44
Post #1789





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (korth @ Feb 20 2012, 15:54) *
QUOTE (lipidicman @ Feb 18 2012, 23:26) *
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [link]
Cheers korth. It is no problem now that I know this. I looked once I got to that post.

Again, this is a documentation issue. I think I'll make an account for the Cuetools wiki.

And I'm happier now that I see it wasn't all the rips I had completed.
Go to the top of the page
+Quote Post
pontomedon
post Feb 24 2012, 11:14
Post #1790





Group: Members
Posts: 2
Joined: 24-February 12
Member No.: 97374



I hope this is the right place to ask - I have the following problem: I ripped a CD (The Lion King OST) in EAC, resulting in a few errors in one track, every other track was verified OK by AccurateRip:

CODE
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 23. February 2012, 20:09

Various / The Lion King OST

Used drive : HL-DT-STDVD-ROM GDR-H30N Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:59.67 | 0 | 17991
2 | 3:59.67 | 2:50.73 | 17992 | 30814
3 | 6:50.65 | 3:40.15 | 30815 | 47329
4 | 10:31.05 | 3:33.50 | 47330 | 63354
5 | 14:04.55 | 2:57.52 | 63355 | 76681
6 | 17:02.32 | 2:55.33 | 76682 | 89839
7 | 19:57.65 | 4:17.50 | 89840 | 109164
8 | 24:15.40 | 3:45.17 | 109165 | 126056
9 | 28:00.57 | 5:59.05 | 126057 | 152986
10 | 33:59.62 | 4:51.50 | 152987 | 174861
11 | 38:51.37 | 3:36.73 | 174862 | 191134
12 | 42:28.35 | 3:59.45 | 191135 | 209104


Range status and errors

Selected range

Filename Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.wav

Suspicious position 0:41:22
Suspicious position 0:41:26

Peak level 98.3 %
Extraction speed 9.3 X
Range quality 99.6 %
Copy CRC 201635C8
Copy finished

There were errors


AccurateRip summary

Track 1 accurately ripped (confidence 5) [8F75F0CE] (AR v2)
Track 2 accurately ripped (confidence 5) [B94FCBF7] (AR v2)
Track 3 accurately ripped (confidence 5) [057830A9] (AR v2)
Track 4 accurately ripped (confidence 5) [9072E0B2] (AR v2)
Track 5 accurately ripped (confidence 5) [45BC209F] (AR v2)
Track 6 accurately ripped (confidence 5) [69A80D86] (AR v2)
Track 7 accurately ripped (confidence 5) [CEFBBEB7] (AR v2)
Track 8 accurately ripped (confidence 5) [54A17B6F] (AR v2)
Track 9 accurately ripped (confidence 5) [377CD6A5] (AR v2)
Track 10 accurately ripped (confidence 5) [5942A28C] (AR v2)
Track 11 cannot be verified as accurate (confidence 94) [AC42013C], AccurateRip returned [47CF4212] (AR v2)
Track 12 accurately ripped (confidence 5) [B2C61F12] (AR v2)

11 track(s) accurately ripped
1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: V1WRWT9HKBEErwwrV9RGpqqiZP8-] found, Submit result: V1WRWT9HKBEErwwrV9RGpqqiZP8- has been submitted
[fc6cb270] (162/168) Differs in 9300 samples @41:20:11-41:20:12,41:20:28-41:20:29,41:20:44-41:20:45,41:20:61-41:20:62,41:21:02-41:21:03,41:21:19-41:21:20,41:21:35-41:21:36,41:21:52-41:21:53,41:21:68-41:21:69,41:22:10-41:22:11,41:22:26-41:22:27,41:22:43-41:22:44,41:22:59-41:22:60,41:23:01-41:23:02,41:23:17-41:23:18,41:23:34-41:23:35,41:23:50-41:23:51,41:23:67-41:23:68,41:24:08-41:24:09,41:24:25-41:24:26,41:24:41-41:24:42,41:24:58-41:24:59,41:24:74-41:25:00,41:25:16-41:25:17,41:25:32-41:25:33,41:25:49-41:25:50,41:25:65-41:25:66,41:26:07-41:26:08,41:26:23-41:26:24,41:26:40-41:26:41,41:26:56-41:26:57,41:26:73-41:26:74,41:27:15,41:27:31-41:27:32,41:27:48,41:27:64-41:27:65,41:28:06,41:28:22-41:28:23
[d03a4fda] (001/168) No match
[557785fe] (001/168) No match
[8036c248] (001/168) No match
[e23534ca] (001/168) No match
[523a016f] (001/168) No match
[9d808615] (001/168) No match
You can use CUETools to repair this rip.



I've never used CUETools before, but i wanted to give it a try to repair the rip. When i load the cue file, and run the encode mode with the repair script selected it verifies the tracks and then stops with the message

CODE
Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.cue: differs in 9300 samples, confidence 163, or verified OK, confidence 1.


Sounds like there are multiple entries in the CTDB database, i might even have uploaded the incorrect one myself, as EAC states "has been submitted" in the log. Is there a possibility to repair the rip?
Go to the top of the page
+Quote Post
lipidicman
post Feb 24 2012, 12:25
Post #1791





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (pontomedon @ Feb 24 2012, 11:14) *
Is there a possibility to repair the rip?

It looks like you are getting the batch mode log, select the cue sheet before you click go. Cuetools should then ask you which entries in CTDB you want to use for the repair.

I've also had a few issues where I've had to ask it to repair several times. Initially it goes through the verify and stops, then the next time it works and I'm not sure why. Someone else might be able to shine some light on this.
Go to the top of the page
+Quote Post
pontomedon
post Feb 24 2012, 12:47
Post #1792





Group: Members
Posts: 2
Joined: 24-February 12
Member No.: 97374



Ah thank you, i was using the batch mode, it worked now.

This post has been edited by pontomedon: Feb 24 2012, 12:48
Go to the top of the page
+Quote Post
lipidicman
post Feb 24 2012, 13:57
Post #1793





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (pontomedon @ Feb 24 2012, 12:47) *
Ah thank you, i was using the batch mode, it worked now.
Glad to help. I've only been using CueTools for a week and I've been doing all the asking until now.
Go to the top of the page
+Quote Post
BrassDude
post Mar 3 2012, 19:41
Post #1794





Group: Members
Posts: 44
Joined: 1-February 11
Member No.: 87835



I'm using the latest version of CUETools 2.1.2a for verifying my rips and populating the CTDB. I found a problem with multi-disc albums that have 5 or more discs if each disc is ripped into multiple tracks. CUETools nicely detects the individual discs if the files are propperly tagged - but only to a maximum of 5 discs. If there are more than 5 disc for that album, all the remaining tracks are grouped in one big disc - the 5th one. Is there a parameter that I can set (max. discs) or is this a bug? Of course if each disc is ripped into a single flac file then there is no problem with the multi-disc albums.
Go to the top of the page
+Quote Post
korth
post Mar 3 2012, 19:56
Post #1795





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



You can switch Input to Multiselect Browser and select cues for more than 5 discs. Detection (as you put it) does max out at 5.

This post has been edited by korth: Mar 3 2012, 20:06


--------------------
korth
Go to the top of the page
+Quote Post
BrassDude
post Mar 4 2012, 04:44
Post #1796





Group: Members
Posts: 44
Joined: 1-February 11
Member No.: 87835



Thanks for your help korth. Can you be a bit more specific - I didn't really understand and see where I can switch to Multiselect Browser.

Also why is this magic number 5 hardcoded? There are many album box-sets out there with definitely more than 5 discs. Maybe that could be a parameter in a future version that one could set under the options. :-)
Go to the top of the page
+Quote Post
korth
post Mar 4 2012, 05:16
Post #1797





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



See the down arrow after Input:? Click on it.
QUOTE
Also why is this magic number 5 hardcoded?
That I can't answer. Only know it from my own usage. Gregory seems quite busy the past few months so I just help out when I can answer a question.


--------------------
korth
Go to the top of the page
+Quote Post
Porcus
post Mar 5 2012, 14:00
Post #1798





Group: Members
Posts: 1959
Joined: 30-November 06
Member No.: 38207



I know I am replying to some > 3 year old post *, but, concerning AccurateRip retro-verification:

QUOTE (Gregory S. Chudov @ Oct 16 2008, 20:47) *
i'm still quite pessimistic about the possibility of recovering an album structure, when tracks were split. Ok, we can sacrifice that split track and focus on verifying other tracks, but for that we have to know for sure it's length.


A suggestion for the case where a cuesheet is absent:
(I) Check files for ACCURATERIPID tags. Then users who use CUERipper, will be able to retro-check AR status later, without the cuesheet (and users who read this forum, could very often get the impression that cuesheets are only useful for writing back a copy ...)
(II) Check files for AccurateRipDISCId tags (my emph.). dBpoweramp writes those. CUERipper and dBpoweramp users are a minority compared to EAC users, but if you consider (I) to be worthwile support for CUERipper users, it should be hardly much effort to do dBpoweramp's tag as well.
(III) Could CDTOC be used the same way? MusicBrainz IDs?


(... 72 pages and counting ... if you could even find information in this thread, you wouldn't know if it is up-to-date :-o )


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
jensend
post Mar 5 2012, 21:16
Post #1799





Group: Members
Posts: 149
Joined: 21-May 05
Member No.: 22191



I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?
Go to the top of the page
+Quote Post
lipidicman
post Mar 5 2012, 22:24
Post #1800





Group: Members
Posts: 119
Joined: 16-March 07
Member No.: 41533



QUOTE (jensend @ Mar 5 2012, 20:16) *
I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?
Because of the way accuraterip works, I would rip the whole CD in track mode then just grab the tracks I wanted. Or you could use EAC.
Go to the top of the page
+Quote Post

104 Pages V  « < 70 71 72 73 74 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 27th November 2014 - 04:21