IPB

Welcome Guest ( Log In | Register )

103 Pages V  « < 67 68 69 70 71 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
korth
post Dec 19 2011, 13:03
Post #1701





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



QUOTE (Porcus @ Dec 19 2011, 11:42) *
I would rather advise users to go to http://www.cuetools.net/wiki/ wink.gif (And then perform a couple of searches, and then ask.)
I had assumed B00ze would use the search feature to look up answers to specific questions as I did in the example.


--------------------
korth
Go to the top of the page
+Quote Post
db1989
post Dec 19 2011, 14:14
Post #1702





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (JeanV @ Dec 19 2011, 02:20) *
How can I split the image with this cue sheet?
[snip]
The gaps look very odd, and I get this error: 'Exception: Indexes must be in chronological order' error.


QUOTE (mjb2006 @ Dec 19 2011, 06:26) *
JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.
Itís never too late! tongue.gif I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which wonít affect splitting or the audio itself anyway.
Go to the top of the page
+Quote Post
JeanV
post Dec 19 2011, 15:40
Post #1703





Group: Members
Posts: 3
Joined: 19-December 11
Member No.: 95883



QUOTE (mjb2006 @ Dec 19 2011, 07:26) *
JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.

What did you use to generate that cue sheet? Or did you just "find" it somewhere? It's damaged beyond repair.

The timestamp after each INDEX ## is supposed to be a position (minutes:seconds:frames format) within most recently mentioned audio FILE (or whichever file you're forcing the cue sheet to be used with). So track 10 index 01 begins at 33:54:45 and track 11 index 01 begins at 38:09:18 ... probably correct. But this means it is nonsensical for track 11 index 00, which is in between, to be at 13:35:66. The story is the same for all the other index 00s.

For splitting, you really only need the index 01s (because you're splitting on track boundaries, and for this disc there's no track 01 index 00 to worry about). So to "fix" the cue sheet, you could delete the INDEX 00 lines, and then it should "work". It no longer represents the original CD, but in this case, that's not a change from the status quo. It didn't represent the original CD properly anyway smile.gif

If you were to use the cue sheet with the index 00s deleted to burn a copy, the resulting CD-R will be mastered with no 'gaps' (places where you see the cd player count from a negative time up to 0:00 at the end of each track). The audio and the main track boundaries will be OK.



QUOTE (db1989 @ Dec 19 2011, 14:14) *
Itís never too late! tongue.gif I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which wonít affect splitting or the audio itself anyway.


Many thanks, mjb2006 and db1989, sorry for missing the codebox tag.

I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 - #142) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?
Go to the top of the page
+Quote Post
db1989
post Dec 19 2011, 15:44
Post #1704





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



Thereís only one way to find out. smile.gif Itís certainly a possibility. Maybe we shouldíve thought of that! tongue.gif
Go to the top of the page
+Quote Post
korth
post Dec 19 2011, 17:21
Post #1705





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



QUOTE (JeanV @ Dec 19 2011, 15:40) *
I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 - #142) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?
In EAC, having the wrong Gap/Index retrieval method can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.

This post has been edited by korth: Dec 19 2011, 18:04


--------------------
korth
Go to the top of the page
+Quote Post
JeanV
post Dec 19 2011, 18:46
Post #1706





Group: Members
Posts: 3
Joined: 19-December 11
Member No.: 95883



QUOTE (korth @ Dec 19 2011, 17:21) *
In EAC, having the wrong Gap/Index retrieval method can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.


Ah, so that's got to do with EAC and how the rip was done beforehand. Now, deleting the INDEX 00 lines is the best bet for me. Thank you. :-)

This post has been edited by JeanV: Dec 19 2011, 18:50
Go to the top of the page
+Quote Post
d3m0n1q_733rz
post Dec 22 2011, 04:04
Post #1707





Group: Members
Posts: 6
Joined: 13-June 11
Member No.: 91465



I've happened upon a bit of a small (though pretty resource intensive) bug that causes CueTools 2.1.2a to keep the takc encoder open when changing an offset fails. I had an offset that I was attempting to change to a positive number when it said there was an error with the stream not allowing seeking. After the failure, the takc.exe program was left running and still attempting to encode. I ended up with 8 of them slowing down my computer before I finally decided to investigate what was being so resource intensive. So you might want to fix this bug in 2.1.2b. I'm also looking for a way to fix some problems with multiple offsets due to sync errors from other programs. I have different songs come up as being accurate with some offsets (-24) and others coming up as no match found. Is it possible to change the software to base the matches of the unmatched songs upon the accurate results of the songs around them so as to increase recovery of extremely poor rips?
For example, if an offset of -24 results in the greatest number of accurate rip results for most songs, it won't necessarily mean it for all songs so matching the results with samples will be difficult. However, if we allow multiple different offsets (different for each song), it will increase the chance of a repair due to sync errors. So, is it unheard of to so such a thing? I would like to make repairs as simple, automated and intelligent as possible. Unfortunately, this means shifting tracks around (filling the shifts with 0s and making them mostly bad samples) until they mostly fit the CRC and then replacing the bad samples afterward to complete the repair.

Let me know what you think!
Go to the top of the page
+Quote Post
fadsplat
post Dec 24 2011, 17:37
Post #1708





Group: Members
Posts: 35
Joined: 23-April 10
From: Canada
Member No.: 80106



Windows 7 Home Premium 64-bit
CueTools 2.1.2a

Hi:

I normally use CueTools in Drag 'n' Drop Mode. One of the reasons is i like the wide window which more easily shows the results and summary line after a Verify operation.

I created Windows "Send To" shortcut so I can right-click a .cue sheet to have it automatically open in CueTools, ready to Verify. However, when CueTools launches this way, it is not in Drag 'n' Drop Mode, ut is instead a tall, narrow window that seems to be Hide Browser mode. I am unable to make that window wider, which makes it awkward to ready Verify results.

1. How can I have CueTools always launch into my preferrred Drag 'n' Drop Mode, even when it launches by a file being sent to it via a Send To shortcut? Are there settings I can change to do this, or some command string or batch file that could launch CueTools with some switches or parameters?

Drag 'n' Drop Mode shows a nice summary of the Verify, e.g. AR: rip accurate (41/41), CTDB: verified OK, confidence 41, but does not show the full .accurip results in the CueTools window. Other modes show full full .accurip results but do not include the nice summary statement.
2. Is there a way to have CueTools display both the summary line and the full results after a Verify?



Thanks

This post has been edited by fadsplat: Dec 24 2011, 17:42
Go to the top of the page
+Quote Post
kotekzot
post Dec 26 2011, 17:12
Post #1709





Group: Members
Posts: 26
Joined: 9-May 06
Member No.: 30599



Hi, I have a couple of rips that CUETools has to do offset correction on to verify against AccurateRip DB. Is there any way to permanently "fix" them, or has the necessary data been lost due to poor ripping?

Also, if a dummy cue sheet passes AR validation, can it be considered exact?

Thanks!

This post has been edited by kotekzot: Dec 26 2011, 17:37
Go to the top of the page
+Quote Post
sauvage78
post Dec 26 2011, 17:56
Post #1710





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



kotekzot:

1: Use Encode\Fix Offset. Default is "fix to nearest". You can change it "fix to highest" in the options.
Nothing is lost as offsets doesn't matter, the only thing you may have lost is the knowledge of which offset was the original one of your CD, but it doesn't really matter as all those pressings that only differs by an offset are equivalent.

Edit: You can also fix them manually one by one if you know exactly which offset you wanna match, just enter the wanted offset in the front offset box & encode. It will be sharper but much longer as nothing will be automatic then.

2: The splitpoints aka INDEX 01 in a CDImage.cue (or Tracks length if you prefer) are correct. Other info of various importance that a CUE can contain are missing.

No new CT version for Christmas ... blah ;(

This post has been edited by sauvage78: Dec 26 2011, 18:42


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
d3m0n1q_733rz
post Dec 27 2011, 20:16
Post #1711





Group: Members
Posts: 6
Joined: 13-June 11
Member No.: 91465



Another bug found! Most recent version of CueRipper errors when you click the track length of a data track. Unhandled exception.
Go to the top of the page
+Quote Post
El Kabong
post Jan 1 2012, 08:01
Post #1712





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



Hey guys, I just downloaded a flac file I verified with CT (as always) which turned out to be a "no match but offset" one. dry.gif

CODE
[CUETools log; Date: 22/12/2011 1:43:39; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track [ CRC ] Status
01 [de1e3119] (0/1) No match
02 [03693299] (0/1) No match
03 [062b2a55] (0/1) No match
04 [9504aee9] (0/1) No match
05 [af53be68] (0/1) No match
06 [9e7138e5] (0/1) No match
07 [55dd40f2] (0/1) No match
08 [7065ff8a] (0/1) No match
09 [0aead0ac] (0/1) No match
Offsetted by -24:
01 [ae80cc09] (0/1) No match but offset
02 [87947cc1] (0/1) No match but offset
03 [20946c45] (0/1) No match but offset
04 [ea57ba99] (0/1) No match but offset
05 [69917058] (0/1) No match but offset
06 [55f7c0dd] (0/1) No match but offset
07 [142944ea] (0/1) No match but offset
08 [2e5f2af2] (0/1) No match but offset
09 [1396e04c] (0/1) No match but offset

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [93962B01] [47181DCC] CRC32
01 96,6 [C19C5852] [9A9B82D7]
02 100,0 [5AB35513] [7237144A]
03 98,0 [D3545233] [02FF9787]
04 98,3 [1F1F7C47] [489EB4AE]
05 97,9 [F6A1F5E0] [C9E2C524]
06 98,2 [7A2F2D39] [20D741B3]
07 97,2 [012EE406] [65418D67]
08 95,8 [A497CE45] [E95C3C68]
09 97,2 [CA6013F4] [1705EC9C]


Well, I ended up burning anyways, offset-correcting in the meantime.
With this my "brand new" CD I repeated the process of ripping & verifying, BUT... now it turned out to be "accurately ripped".

CODE
[CUETools log; Date: 01/01/2012 3:10:10; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track [ CRC ] Status
01 [ae80cc09] (0/1) No match but offset
02 [87947cc1] (0/1) No match but offset
03 [20946c45] (0/1) No match but offset
04 [ea57ba99] (0/1) No match but offset
05 [69917058] (0/1) No match but offset
06 [55f7c0dd] (0/1) No match but offset
07 [142944ea] (0/1) No match but offset
08 [2e5f2af2] (0/1) No match but offset
09 [1396e04c] (0/1) No match but offset
AccurateRip v2:
01 [cff94e79] (1/1) Accurately ripped
02 [9d16df24] (1/1) Accurately ripped
03 [3d30d8f8] (1/1) Accurately ripped
04 [08b4a99a] (1/1) Accurately ripped
05 [df62cb36] (1/1) Accurately ripped
06 [77080667] (1/1) Accurately ripped
07 [9a55ed90] (1/1) Accurately ripped
08 [34e7f011] (1/1) Accurately ripped
09 [40d8ff09] (1/1) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [D079E009] [47181DCC] CRC32
01 96,6 [4D444A54] [9A9B82D7]
02 100,0 [D843C366] [7237144A]
03 98,0 [F3E83C36] [02FF9787]
04 98,3 [6F92B98A] [489EB4AE]
05 97,9 [497DC845] [C9E2C524]
06 98,2 [365EF879] [20D741B3]
07 97,2 [11BFDF1F] [65418D67]
08 95,8 [C3D27F4A] [E95C3C68]
09 97,2 [C0B98852] [1705EC9C]


Can someone tell me why doesn't CT warn of this ARv2 match for the offset(-24) instead of stating this misleading message.
I've been discarding all those "no match but offset" since long ago taking them for bad rips, and now I suddenly come across they were all probably good. mad.gif

Thanks in advance!

This post has been edited by El Kabong: Jan 1 2012, 08:07
Go to the top of the page
+Quote Post
Goratrix
post Jan 1 2012, 11:16
Post #1713





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



First, it's not nice to talk about verifying illegal downloads in this thread, CueTools was not designed for that purpose. Second, AR2 verification does not perform offset checking. There was a debate between Spoon and Gregory a few months ago in this thread, and Gregory said that AR2 verification across pressings is too time consuming or something, so it's not implemented (yet?).
Go to the top of the page
+Quote Post
sauvage78
post Jan 1 2012, 12:30
Post #1714





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



Actually CT only display ARv2 results on the actual offset, I think displaying ARv2 results on other offsets is planned for a future version.
The actual way of displaying was thought for ARv1, actually displaying ARv2 is more a quick "hack" than anything else.
The full support of ARv2 is on the TODO list, but I agree it is taking too much time, according to me there are several reasons for this:
1- There was a disagreement between Spoon & Gregory about the usefullness of ARv2, now Gregory is more or less "forced" to support something he didn't asked for (as time goes by, I tend to agree with Gregory personnaly)
2- With full ARv2 support the displaying of log might completely change as Gregory posted an idea of horizontal log displaying in order to avoid very long vertical logs, reinventing the wheel might take longer than expected.
3- I suspect Gregory is more or less willing to make CTDB independent from AR as I suspect that despite his diplomatic behavior he didn't appreciated that much how ARv2 was implemented without his help. Gregory already stated that there is no CRC that AR stores & that CTDB doesn't store anymore. In the beginning CTDB was AR dependent, because both were using different CRC (tracks vs image) if I recall correctly. (Don't slam me if I am wrong Greynol !)
4- The introduction of the CTDB plugin for EAC makes the future of CT even harder to read, as it seems very efficient in term of submissions (even bad ones). Will there be a CTDB plugin for dBpoweramp in order to have a single database for all rippers dBpoweramp/Cueripper/EAC ??? I doubt Spoon would like the idea much ... will Gregory work with EAC more closely ? no one knows.
5- Gregory just get married & is currently cheating his computer. Full ARv2 support would certainly be faster if he would have wed Spoon. (Just Kidding Spoon !)

Anyway it would be great If Gregory could clear the future of the CTDB for 2012. I mean we all see what should be fixed or improved in CT, but actually we are at a point where any further CT development is dependent on how Spoon/Gregory/Andree are willing ... or not willing ... to work together on an harmonized verification\correction database.

As an end user, the way I see it: there is Spoon on one side & Gregory & Andree on the other, because Spoon already has his baby [AR which is GREAT, no discussion] & because Spoon sells software [which means he wants to keep control of his business which is natural]. Furthermore the recent past (ARv2) has shown that Gregory & Spoon didn't work that well together. As far as I understood both have respect for each other works as developpers, but none (well to be honest specially Spoon IMHO) is willing to let the other introduce himself in his own business. It is likely that Spoon invested too much time in AR development to drop it in favor of a cross-ripper improved CTDB platform. Furthermore is Gregory really wiling to achieve the development & manage such a platform ? For me there are hints that shows we tend toward this, but the fact that there is actually no futher CT visible development is also an hint that Gregory has a lot of hesitation himself ... because with or without the help of Spoon & Andree ... it's likely a lot of work.

Be warned, some of the above might be complete bullshits due to high speculation wink.gif It's new year day & maybe I'm still drunk. emot-toot.gif


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
spoon
post Jan 1 2012, 13:01
Post #1715


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2746
Joined: 24-March 02
Member No.: 1615



ARv2 was a simple fix to a flaw, it required about 10 minutes of programming effort to implement in a program which already uses ARv1. Despite all the talk about how CRC32 should have been used, I have never seen a false positive from AR, also ARv1 CRC is there also, so potentially you have 64 bits of CRC!

I have always said, for a program to state is compatible with ARv2 it should use the offset CRCs to check across pressings, this is efficient (typically a CD will have 4 offsets which need checking), after all we are not computing the next unknown prime number, just simple CRCs on audio.

AccurateRip is being worked on to allow the ~99.99999% of people who do not use a secure ripper to be able to verify their rips, and possibly correct bad rips, whilst being able to work on single files. I am sure I am not alone when I rip an album, listen to the tracks I like and delete the ones I do not like.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
sauvage78
post Jan 1 2012, 13:23
Post #1716





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



The biggest problem with CT not fully supporting ARv2 is that ARv1 submissions has more or less stopped (didn't hunt to verify if it's completely stopped), so with recent CD (post ARv2 introduction), ARv2 is often more populated than ARv1 ... & with CT not fully supporting ARv2 you don't see the whole picture of submissions anymore. If you don't fix offset while ripping, with a "post ARv2 introduction" new CD ... you may completely miss the submissions as those will be invisible.

It's also a problem when "fixing to highest" offset in database, nowadays I am unable to guess if it's already "fixed to highest" as I miss "half" (exagerating but sooner or later it will be half) of the submissions, & I am sure that it introduces other missbehaviors with other uses of CT than mine.

This post has been edited by sauvage78: Jan 1 2012, 13:25


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
El Kabong
post Jan 1 2012, 20:53
Post #1717





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



All clearer now thanks to your replies, sauvage78 & spoon.
I'm not an everyday forum visitor (cause I have to take care of my own "illegal" forum dry.gif ), so I didn't know it already was in a TODO list. Hope it soon get implemented in a vertical log display way (preferably) so we can catch the full picture. It would be of great use for fighting people's laziness who tends to do untidy works, sometimes not even correcting their drives' offsets... or what's worse: enabling enconding & decoding offset correction! blink.gif. Thus making us other users waste our precious time. Still more, not to mention those unaware of EAC!!!
Personal benefits aside, best wishes for a near future agreement upon such a feature so needed by end users.

Cheers & Happy New Year! emot-toot.gif

PS (to whom it may concern): As for today, US laws are not worldwide applicable... fortunately. rolleyes.gif
Go to the top of the page
+Quote Post
mjb2006
post Jan 2 2012, 02:53
Post #1718





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



QUOTE (El Kabong @ Jan 1 2012, 12:53) *
sometimes not even correcting their drives' offsets

That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Besides, if those drives couldn't overread, then you know the samples at the very beginning or end of the rip were actually read from the CD, rather than padded with zeroes. So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons. smile.gif
Go to the top of the page
+Quote Post
El Kabong
post Jan 2 2012, 07:00
Post #1719





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



QUOTE (mjb2006 @ Jan 1 2012, 21:53) *
That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Regarding ARv2 verification, I guess my example speaks by itself.
What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

QUOTE (mjb2006 @ Jan 1 2012, 21:53) *
So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

No point of discussion here. Of course, it's not that important but very useful indeed. Otherwise, it wouldn't even have ever got implemented... I suppose.
That's why I trust CT so hard.

QUOTE (mjb2006 @ Jan 1 2012, 21:53) *
Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons. smile.gif

Let's say I was sneaking my cousin's machine then.
Ssssh! wink.gif
Go to the top of the page
+Quote Post
Goratrix
post Jan 2 2012, 11:09
Post #1720





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



QUOTE (El Kabong @ Jan 2 2012, 08:00) *
What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

Buy the CD? rolleyes.gif
Go to the top of the page
+Quote Post
korth
post Jan 12 2012, 17:25
Post #1721





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



Gregory,
I know you're working on CTDB 2.0 and 'ignore pregap' was the last thing you worked on but what's this?
QUOTE
CTDB: disk not present in database, submit: discs with pregaps not supported in this protocol version.
Looks like discs with pregaps are being rejected in the current CTDB. I don't recall having this message come up on previous submissions.

This post has been edited by korth: Jan 12 2012, 18:03


--------------------
korth
Go to the top of the page
+Quote Post
Anakunda
post Jan 14 2012, 20:59
Post #1722





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



I've go strange error when starting conversion, Stream doesnot support lookup.
What does it mean and how to fix it? Thanks.
Go to the top of the page
+Quote Post
korth
post Jan 19 2012, 18:56
Post #1723





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



QUOTE
discs with pregaps not supported in this protocol version.
Looks like I get the same CTDB message with CUERipper on discs with pregap.


--------------------
korth
Go to the top of the page
+Quote Post
Anakunda
post Jan 19 2012, 21:40
Post #1724





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



HI I see that CUEtools doesnot copy ISRC codes from original CUEsheet to new CUEsheet, could it be fixed in next version?
Go to the top of the page
+Quote Post
Anakunda
post Jan 23 2012, 16:29
Post #1725





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



I suppose here's another shortcoming: copying old LOG file to new destination converts from Unicode to ANSI. This is basically bad because since this the LOG file can't be checked by EAC log verifier anymore (it only can read LOG files in Unicode). If possible please copy it raw (no codepage conversion). If I overlooked something in options then sorry but I think not, only options to forcing ANSI deals with file names which is different thing.
Go to the top of the page
+Quote Post

103 Pages V  « < 67 68 69 70 71 > » 
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: 16th September 2014 - 15:57