IPB

Welcome Guest ( Log In | Register )

103 Pages V  « < 57 58 59 60 61 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
Marc27
post Jun 27 2011, 08:07
Post #1451





Group: Members
Posts: 40
Joined: 5-May 11
Member No.: 90377



I put together the tracks from a log posted by Sauvage78 (track 01 & 02) and a case example posted by Gregory (track 03).
I should have mentioned it...

On a side note, I'm not sure what happens with ARv2 information and alternate offsets. I may take a look at more ARv2 logs once I get my computer back.

This post has been edited by Marc27: Jun 27 2011, 08:18
Go to the top of the page
+Quote Post
greynol
post Jun 27 2011, 11:14
Post #1452





Group: Super Moderator
Posts: 10043
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I suppose I should at least look at a log before giving my $0.02.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Anakunda
post Jun 28 2011, 09:08
Post #1453





Group: Members
Posts: 473
Joined: 24-November 08
Member No.: 63072



I have feature request, please preserve existing replaygain information after conversion
Go to the top of the page
+Quote Post
HotShotFR
post Jun 28 2011, 11:15
Post #1454





Group: Members
Posts: 29
Joined: 11-August 07
From: Germany
Member No.: 46130



QUOTE (Anakunda @ Jun 28 2011, 10:08) *
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request biggrin.gif please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).
Go to the top of the page
+Quote Post
Anakunda
post Jun 28 2011, 11:30
Post #1455





Group: Members
Posts: 473
Joined: 24-November 08
Member No.: 63072



QUOTE (HotShotFR @ Jun 28 2011, 12:15) *
QUOTE (Anakunda @ Jun 28 2011, 10:08) *
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request biggrin.gif please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).


That's right for ->loosy, but I talked about lossless->losless where no clipping or normalization is applied biggrin.gif
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.

This post has been edited by Anakunda: Jun 28 2011, 11:32
Go to the top of the page
+Quote Post
HotShotFR
post Jun 28 2011, 13:51
Post #1456





Group: Members
Posts: 29
Joined: 11-August 07
From: Germany
Member No.: 46130



QUOTE (Anakunda @ Jun 28 2011, 12:30) *
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.

Would be great, and there are different 'kinds' of RG so far (vanilla vs. EBU R128) thus a config option would be welcome.


Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)

This post has been edited by HotShotFR: Jun 28 2011, 13:52
Go to the top of the page
+Quote Post
No Fun
post Jun 29 2011, 21:45
Post #1457





Group: Members
Posts: 24
Joined: 8-April 04
Member No.: 13334



Thanks, Gregory!

Seems that "Verify only if found" doesn't take in account present CTDB-entry even if "Use CTDB" checked. I suppose it should.

Go to the top of the page
+Quote Post
El Kabong
post Jun 30 2011, 08:10
Post #1458





Group: Members
Posts: 18
Joined: 31-May 10
Member No.: 81038



I'm still accustoming to the new log, so I know for sure you will wisely spare. biggrin.gif

Is this rip accurate or not?
CODE
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: gVxhEOQHHEPNFvQ9qjE12ZbNjmU-] found.
[ CTDBID ] Status
[085e4f05] (2/2) Accurately ripped
[AccurateRip ID: 000a1243-003624b0-3c0a3c06] found.
Track [ CRC ] Status
01 [d0c6fdd1] (0/2) No match but offset
02 [5793ed0e] (0/2) No match but offset
03 [8621b7af] (0/2) No match but offset
04 [506332c0] (0/2) No match but offset
05 [b5862057] (0/2) No match but offset
06 [bd42b7cc] (0/2) No match but offset
AccurateRip v2:
01 [057f19b3] (2/2) Accurately ripped
02 [442fd49a] (2/2) Accurately ripped
03 [14e4a138] (2/2) Accurately ripped
04 [f0486f43] (2/2) Accurately ripped
05 [05bcb5a6] (2/2) Accurately ripped
06 [76cec823] (2/2) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [2944617A] [5D2AC446] CRC32
01 100,0 [BA67ECCA] [BB1C7900]
02 100,0 [B721AA8D] [4E492126]
03 100,0 [F7562C3A] [B60E0DED]
04 100,0 [24376FAD] [C3AC539F]
05 99,5 [C95E7F53] [0D31B664]
06 99,2 [9AD39544] [276F7423]

I guess no. Do you?
Go to the top of the page
+Quote Post
korth
post Jun 30 2011, 13:49
Post #1459





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



QUOTE (El Kabong @ Jun 30 2011, 07:10) *
I'm still accustoming to the new log, so I know for sure you will wisely spare. biggrin.gif

Is this rip accurate or not?

I guess no. Do you?


I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read this and this.

Does it really look that different?

CODE
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped




This post has been edited by korth: Jun 30 2011, 14:17


--------------------
korth
Go to the top of the page
+Quote Post
sauvage78
post Jun 30 2011, 16:06
Post #1460





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.

This post has been edited by sauvage78: Jun 30 2011, 16:30


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
TBeck
post Jun 30 2011, 20:22
Post #1461


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (HotShotFR @ Jun 28 2011, 14:51) *
Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

I don't know CUEtools, but i think this should be easy to implement. Does it take more than storing the data as APEv2 tags, which is the standard for TAK?

QUOTE (HotShotFR @ Jun 28 2011, 14:51) *
Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)

Unfortunately TAKC currently does not have an option to extract only a part of a compressed file. Sorry... I will put it on my to do list.
Go to the top of the page
+Quote Post
El Kabong
post Jul 1 2011, 01:34
Post #1462





Group: Members
Posts: 18
Joined: 31-May 10
Member No.: 81038



QUOTE (korth @ Jun 30 2011, 09:49) *
I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read this and this.

Does it really look that different?

CODE
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped
As sauvage stated some pages back: 'what I don't really understand is why AR V2 reports "No match but offset" instead of simply "No match"'. That "No match but offset" sounds like a bad rip to me too. unsure.gif


QUOTE (sauvage78 @ Jun 30 2011, 12:06) *
It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. wink.gif
Here's the EAC log for that rip.

CODE
AccurateRip summary

Track 1 cannot be verified as accurate (confidence 2) [D0C6FDD1], AccurateRip returned [057F19B3]
Track 2 cannot be verified as accurate (confidence 2) [5793ED0E], AccurateRip returned [442FD49A]
Track 3 cannot be verified as accurate (confidence 2) [8621B7AF], AccurateRip returned [14E4A138]
Track 4 cannot be verified as accurate (confidence 2) [506332C0], AccurateRip returned [F0486F43]
Track 5 cannot be verified as accurate (confidence 2) [B5862057], AccurateRip returned [05BCB5A6]
Track 6 cannot be verified as accurate (confidence 2) [BD42B7CC], AccurateRip returned [76CEC823]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

Regards!
Go to the top of the page
+Quote Post
korth
post Jul 1 2011, 04:29
Post #1463





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



QUOTE (El Kabong @ Jul 1 2011, 00:34) *
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. wink.gif
Here's the EAC log for that rip.

CODE
AccurateRip summary

Track 1 cannot be verified as accurate (confidence 2) [D0C6FDD1], AccurateRip returned [057F19B3]
Track 2 cannot be verified as accurate (confidence 2) [5793ED0E], AccurateRip returned [442FD49A]
Track 3 cannot be verified as accurate (confidence 2) [8621B7AF], AccurateRip returned [14E4A138]
Track 4 cannot be verified as accurate (confidence 2) [506332C0], AccurateRip returned [F0486F43]
Track 5 cannot be verified as accurate (confidence 2) [B5862057], AccurateRip returned [05BCB5A6]
Track 6 cannot be verified as accurate (confidence 2) [BD42B7CC], AccurateRip returned [76CEC823]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

Regards!


EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2. CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.


--------------------
korth
Go to the top of the page
+Quote Post
Kevin04
post Jul 1 2011, 12:23
Post #1464





Group: Members
Posts: 13
Joined: 21-July 10
Member No.: 82417



It would be great if the 'Correct filenames'-action would create UTF8-encoded CUEs when necessary. At the moment, it substitutes every non-ANSI character with a ?. Therefore, I'm using the 'Encode'-action without audio output and without using any databases to fix the filenames, as that creates unicode CUEs if needed.
However, that doesn't always work as expected though: I thought, when turning off all checkboxes in the 'Tagging'-settings, it would keep everything besides filenames and structure as it is. But for some CUEs/discs, it just removes some REM or CD-TEXT lines. Sometimes it even adds empty CD-TEXT lines (like PERFORMER "") when there were none before. So I need to check the fixed cue against the original manually everytime I do that.
An option to allow/prevent CUETools from creating such CUEs might be a good idea, I bet there are people who don't want it.
Go to the top of the page
+Quote Post
Anakunda
post Jul 2 2011, 10:27
Post #1465





Group: Members
Posts: 473
Joined: 24-November 08
Member No.: 63072



I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

1 question:
What exactly does fix offset script with encode. I have verified on rip with shifted offset. As best match was results with +6 offset. If chosing Encode+fix offset, the progress failed. If chosen Encode+normal and manually giving offset +6, the progress succeed and offset was fixed. Then what's 'fix offset' good if it can't find correct offset value and apply for reencode. If the offset is obvious from verify results set.

What about the RG rescan? It's not as hard to do by another tool but I forget often to do that. At least preserve existing tags.
Go to the top of the page
+Quote Post
ebaboon
post Jul 2 2011, 23:40
Post #1466





Group: Members
Posts: 5
Joined: 27-January 09
Member No.: 66105



To Anakunda:
QUOTE (Anakunda @ Jul 2 2011, 10:27) *
I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

It’s Not A Bug, It’s A Feature! smile.gif
QUOTE (Gregory S. Chudov @ Oct 10 2008, 11:00) *
"Verify" also writes AR tags in source file on success, but currently only flac album image (with embedded cue) is supported for this.


To Gregory:
Now CUETools after encode, change multivalue tags (album, genre, artist, title) in comma separate one-value form. Example, i have multivalue genre "Jazz-Funk;Soul" after encode genre is one-value "Jazz-Funk, Soul". Please add options to copy this multivalue tags as is, whitout any change.
Go to the top of the page
+Quote Post
El Kabong
post Jul 3 2011, 02:37
Post #1467





Group: Members
Posts: 18
Joined: 31-May 10
Member No.: 81038



QUOTE (korth @ Jul 1 2011, 00:29) *
EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2. CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.

Oops! wub.gif Sometimes I completely forget about this new feature.
This is my very first rip with ARv2 support. Hope to be spared! rolleyes.gif
Thanks for your ready guide, korth! wink.gif
By the way, here's the new log...
CODE
Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 2. July 2011, 21:10

Jakszyk, Fripp & Collins / A Scarcity of Miracles

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

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

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 : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Archivos de programa\Exact Audio Copy [v1.0b1]\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%albumtitle%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "COMMENT=EAC (Secure Mode)" %source% -o %dest%


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 7:26.67 | 0 | 33516
2 | 7:26.67 | 4:47.13 | 33517 | 55054
3 | 12:14.05 | 7:47.51 | 55055 | 90130
4 | 20:01.56 | 8:37.14 | 90131 | 128919
5 | 28:38.70 | 5:59.27 | 128920 | 155871
6 | 34:38.22 | 9:02.18 | 155872 | 196539


Range status and errors

Selected range

Filename D:\Lossless\Jakszyk, Fripp & Collins - A Scarcity of Miracles\Jakszyk, Fripp & Collins - A Scarcity of Miracles.wav

Peak level 100.0 %
Extraction speed 6.2 X
Range quality 100.0 %
Copy CRC 2944617A
Copy OK

No errors occurred


AccurateRip summary

Track 1 accurately ripped (confidence 2) [057F19B3] (AR v2)
Track 2 accurately ripped (confidence 2) [442FD49A] (AR v2)
Track 3 accurately ripped (confidence 2) [14E4A138] (AR v2)
Track 4 accurately ripped (confidence 2) [F0486F43] (AR v2)
Track 5 accurately ripped (confidence 2) [05BCB5A6] (AR v2)
Track 6 accurately ripped (confidence 2) [76CEC823] (AR v2)

All tracks accurately ripped

End of status report

==== Log checksum 4821C1E0A71ED22BCC5575B6E56F7FC9E954073131B8FB700CAECD62A25988AF ====

Just nice!
Regards!
Go to the top of the page
+Quote Post
prefab
post Jul 6 2011, 15:23
Post #1468





Group: Members
Posts: 29
Joined: 17-September 09
Member No.: 73270



Gregory, thank you very much for 2.1.2a

Any chance of writing the ACCURATERIP tags to ALAC ? Cheers
Go to the top of the page
+Quote Post
mind_vs_body
post Jul 8 2011, 14:45
Post #1469





Group: Members
Posts: 5
Joined: 15-November 08
Member No.: 62481



Hello, I have been using a way old CueTools version, and have just upgraded to the 2.1.2 version, which I am pleasantly surprised at evolution of new features :-) Also appreciating mirroring the syntax used in foobar.

Is it possible to use CueTools to convert a FLAC image and Cue to tracks with revised Cue, and preserve the custom tags? I see a setting in Advanced>Tagging "Copy unknown tags" which I thought would do this, but it is only copying standard tags (artist, title, etc). If it is possible would that also include ReplayGain? I'm guessing no from comments just above...

I know I can always use foobar to split to tracks and preserve the tags, and then batch convert the cues with CUE Tools, but would be great to do in one shot. If this is already answered somewhere else in the thread please point my weary eyes there :-) Thank you.
Go to the top of the page
+Quote Post
Kevin04
post Jul 9 2011, 15:22
Post #1470





Group: Members
Posts: 13
Joined: 21-July 10
Member No.: 82417



Would it be possible to add an option for keeping the timestamps of a file when converting or correcting it?

Also, a question about error messages. Like here in that accurip
QUOTE
[CTDB TOCID: FodNAscYq_hxDOrxrgrUq6AcLBc-] database access error: Timeout für Vorgang überschritten.

and here from a EAC log (with the CTDB plugin, obviously)
QUOTE
[CTDB TOCID: rQdoeISrw6aMymKgoVQkFW5VbHk-] found, Submit result: database access error: Die Anfrage wurde abgebrochen: Die Anfrage wurde abgebrochen..

Why is a part of it in German? Is it because my OS locale is German? Both programs are set to English, in EAC even the 'always-english-log'-option is set. Can I do something about it?
And while we're at it, I think the submit results shouldn't be included in a EAC log, just the verify results. But that's just my opinion.
Go to the top of the page
+Quote Post
Pegasus_ST
post Jul 11 2011, 15:53
Post #1471





Group: Members
Posts: 2
Joined: 11-July 11
Member No.: 92202



Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you
Go to the top of the page
+Quote Post
a3aan
post Jul 11 2011, 16:43
Post #1472





Group: Members
Posts: 80
Joined: 23-December 06
Member No.: 38930



The latest CUERipper V2.1.2a doesn't write accurip tags to my flac files. Is this a known issue?
Go to the top of the page
+Quote Post
Pegasus_ST
post Jul 11 2011, 17:21
Post #1473





Group: Members
Posts: 2
Joined: 11-July 11
Member No.: 92202



QUOTE (Pegasus_ST @ Jul 11 2011, 15:53) *
Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you


The problem is found.

Source files are recoded to 48kHz. Why FLAC? sad.gif

It will be good if program can report something like this:
"The source files are not seems to be a CD audio.
Reason: Sample rate is 48kHz"

The suggestion is based on the WAVTools message smile.gif
Go to the top of the page
+Quote Post
ManekiNeko
post Jul 11 2011, 19:20
Post #1474





Group: Members
Posts: 79
Joined: 7-April 09
Member No.: 68742



Using 2.1.2a, converting individual flac files to 1 file-per-album tta+cue, the tta files have apev2 tags. Shouldn't they be ID3 tags? Are apev2 tags now complient in tta files?
Go to the top of the page
+Quote Post
squidbear
post Jul 11 2011, 19:35
Post #1475





Group: Members
Posts: 5
Joined: 9-July 11
Member No.: 92155



While trying to rip "All We Know Is Falling" by Paramore using CUERipper on one of my drives (ASUS CRW-5232AX 1.01), I received the following error message while or immediately after detecting for gaps:

"Exception: Error reading CD: NO SENSE STRING FOR ASC=02, ASCQ=00"

So I tried ripping the CD using my other drive and it ripped perfectly with no issues. Now, I've used my ASUS drive with CUERipper for the past few days and have successfully ripped 20-30 CDs with no problems occurring.

Any ideas as to why this is happening now? Is it the software or my hardware (or both)? If it's strictly a hardware issue, then perhaps a more comprehensive error message would be a helpful improvement for CUERipper's error handling system.

This post has been edited by squidbear: Jul 11 2011, 19:36
Go to the top of the page
+Quote Post

103 Pages V  « < 57 58 59 60 61 > » 
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: 24th October 2014 - 08:36