IPB

Welcome Guest ( Log In | Register )

103 Pages V  « < 98 99 100 101 102 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
ChronoSphere
post Mar 20 2014, 20:18
Post #2476





Group: Members
Posts: 491
Joined: 11-March 07
Member No.: 41384



QUOTE (acrox999 @ Mar 19 2014, 08:39) *
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:


I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters.
If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.
Go to the top of the page
+Quote Post
acrox999
post Mar 21 2014, 02:52
Post #2477





Group: Members
Posts: 41
Joined: 18-November 08
Member No.: 62650



QUOTE (ChronoSphere @ Mar 21 2014, 03:18) *
QUOTE (acrox999 @ Mar 19 2014, 08:39) *
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:

<image>

I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters. If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.


Thanks, I've disabled it for now. But my DVD drive died, yet again, after ripping few CDs consecutively. I knew I shouldn't have ripped that album, lots of scratches, and the error check must have strained it too much. I'll try this when I get myself a new drive.

Go to the top of the page
+Quote Post
plugs13amp
post Apr 11 2014, 10:44
Post #2478





Group: Members
Posts: 4
Joined: 11-April 14
Member No.: 115467



I've been using CUETools (2.1.4) to rip all my 500+ cds to flac. This was done across several machines to speed the process up and in some cases to get an accurate rip. Is there any way to merge the local databases onto one machine. I know I can merge the metadata, but any imported metadata files are not seen when I try to convert the flacs to mp3, only the cues are shown.

thanks
Go to the top of the page
+Quote Post
korth
post Apr 23 2014, 16:47
Post #2479





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



QUOTE (ChronoSphere @ Mar 20 2014, 19:18) *
QUOTE (acrox999 @ Mar 19 2014, 08:39) *
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:
{image removed from quote}
I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters.
If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.

CUERipper has a separate settings file. If running as Windows app it can be found under %appdata% or if running as portable app it can be found in the CUETools program folder. Look for \CUERipper\settings.txt
Change
FilenamesANSISafe=1 (Force ANSI Filenames)
to
FilenamesANSISafe=0 (Don't Force ANSI Filenames)

Test results: File names and Unicode M3U file OK with Cyrillic characters but CUE and LOG were saved as ANSI files so Cyrillic characters are still replaced by question marks.


--------------------
korth
Go to the top of the page
+Quote Post
nospamorban
post May 3 2014, 18:36
Post #2480





Group: Members
Posts: 7
Joined: 9-December 13
Member No.: 113082



I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Cuetools v2.1.4
Avast! Free Antivirus 2014.9.0.2018
Virus Definition Ver: 140503-0



I have run a full scan my PC and it hasn't found a virus.

I deleted the old CT folder, redownloaded CT and it still gives me a virus alert when I try to start CT. And each time its a different .dll file that's moved to the virus chest.

Should I clean install Windows? Have I really got a virus or is this a false positive?


This post has been edited by nospamorban: May 3 2014, 18:38
Go to the top of the page
+Quote Post
Zarggg
post May 3 2014, 19:34
Post #2481





Group: Members
Posts: 556
Joined: 18-January 04
From: bethlehem.pa.us
Member No.: 11318



What is the full path of the file in question?
Go to the top of the page
+Quote Post
nospamorban
post May 3 2014, 20:30
Post #2482





Group: Members
Posts: 7
Joined: 9-December 13
Member No.: 113082



QUOTE (Zarggg @ May 4 2014, 02:34) *
What is the full path of the file in question?


C:\Users\Admin\AppData\Local\Temp
Go to the top of the page
+Quote Post
nospamorban
post May 4 2014, 10:18
Post #2483





Group: Members
Posts: 7
Joined: 9-December 13
Member No.: 113082



QUOTE (nospamorban @ May 4 2014, 01:36) *
I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Pretty sure it's a false positive.
I loaded a new VM with just CUETools and Avast and it still produces a virus warning when I start CUETools.
I have reported it to Avast...I wonder how long they'll take to remedy the situation.
Go to the top of the page
+Quote Post
ChronoSphere
post May 4 2014, 20:19
Post #2484





Group: Members
Posts: 491
Joined: 11-March 07
Member No.: 41384



The "-gen [susp]" ending means it's a generic signature, the heuristics picked it up as a suspicious file. So yeah, a false positive. You can add the file to exclusions in the meantime.

edit: I just noticed the thread title states 2.1.5 is current, but the page still lists it as unstable/experimental. Is this intended?

This post has been edited by ChronoSphere: May 4 2014, 20:21
Go to the top of the page
+Quote Post
cherry99
post May 8 2014, 02:03
Post #2485





Group: Members
Posts: 2
Joined: 7-May 14
Member No.: 115961



Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
If metadata is in english both Id3v1 and Id3v2 tags are correct.
As suggested by korth in post #2479 I changed FilenamesANSISafe=1 to FilenamesANSISafe=0 in both settings.txt files but this had no effect on Id3v1.

Any ideas how to fix this?
Or which settings to change in order not to create Id3v1 tags at all?

Thanks






Go to the top of the page
+Quote Post
evildeathinc
post May 8 2014, 03:45
Post #2486





Group: Members
Posts: 7
Joined: 15-February 14
Member No.: 114490



Cuetools 2.1.4 recently Crashed. Windows 7 x64 Operating System. Please Help.

Here is the Error found.

Problem Event Name: CLR20r3
Problem Signature 01: cuetools.exe
Problem Signature 02: 2.1.4.0
Problem Signature 03: 4ffe16f6
Problem Signature 04: mscorlib
Problem Signature 05: 2.0.0.0
Problem Signature 06: 5265c965
Problem Signature 07: 34a9
Problem Signature 08: e1
Problem Signature 09: System.IO.FileNotFoundException
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Go to the top of the page
+Quote Post
ChronoSphere
post May 8 2014, 14:32
Post #2487





Group: Members
Posts: 491
Joined: 11-March 07
Member No.: 41384



QUOTE (cherry99 @ May 8 2014, 03:03) *
Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
From what I know, ID3v1 is ANSI only. This means, your locale has to be set to Russian while writing Russian tags, and they will only appear as such as long as you have your system locale set to Russian.
ID3v2.x on the other hand support unicode (UTF-16 for v2.3 and UTF-8 for v2.4 afaik), which is the reason why the tags are correct even if your locale is not set to Russian.

Why are you writing v1 tags in the first place? If you don't have to keep compatibility with old devices, don't write ID3v1 at all.
Go to the top of the page
+Quote Post
cherry99
post May 8 2014, 18:59
Post #2488





Group: Members
Posts: 2
Joined: 7-May 14
Member No.: 115961



QUOTE (ChronoSphere @ May 8 2014, 09:32) *
QUOTE (cherry99 @ May 8 2014, 03:03) *
Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
From what I know, ID3v1 is ANSI only. This means, your locale has to be set to Russian while writing Russian tags, and they will only appear as such as long as you have your system locale set to Russian.
ID3v2.x on the other hand support unicode (UTF-16 for v2.3 and UTF-8 for v2.4 afaik), which is the reason why the tags are correct even if your locale is not set to Russian.

Why are you writing v1 tags in the first place? If you don't have to keep compatibility with old devices, don't write ID3v1 at all.

I would prefer not to write ID3v1 tags but CUETools always creates them automatically. If anyone knows how to stop ID3v1 creation please let me know.

My locale was always set to Russian, so that is not the reason.

To isolate the problem I did the following test:
I ripped a CD with EZ CD Audio Converter in Russian locale and both ID3v1 and ID3v2 were written correctly.
Then I changed locale to English (United States) and ripped the same CD with EZ CD Audio Converter and again both ID3v1 and ID3v2 were written correctly.
Then I repeated the same process with CUERipper and ID3v1 tags were always written with question marks instead of letters.
The conclusion: It is not the System Locale that is responsible for wrong ID3v1 characters but something in CUETools. But what...?

Any suggestions?

Ripped by EZ CD Audio Converter



Ripped by CUERipper

Go to the top of the page
+Quote Post
plugs13amp
post May 11 2014, 09:40
Post #2489





Group: Members
Posts: 4
Joined: 11-April 14
Member No.: 115467



QUOTE (nospamorban @ May 3 2014, 18:36) *
I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Cuetools v2.1.4
Avast! Free Antivirus 2014.9.0.2018
Virus Definition Ver: 140503-0



Avast still flagging CueTools as infected on 11th May 2014

I've also now reported the problem to Avast, maybe those of us experiencing the problem can report it, to push them along.

The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 11 2014, 23:51
Post #2490





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (cherry99 @ May 8 2014, 12:59) *
The conclusion: It is not the System Locale that is responsible for wrong ID3v1 characters but something in CUETools. But what...?

CUETools uses taglib-sharp to write tags. By default, taglib-sharp follows the ID3v1 standard and uses Latin-1 encoding for ID3v1 tags, which means that non-Latin-1 characters are replaced by '?'.
There is however an option in taglib-sharp which changes it's behaviour:
CODE
        /// <summary>
        ///    Gets and sets whether or not to use a broken behavior for
        ///    Latin-1 strings, common to ID3v1 and ID3v2 tags.
        /// </summary>
        /// <value>
        ///    <see langword="true" /> if the broken behavior is to be
        ///    used. Otherwise, <see langword="false" />.
        /// </value>
        /// <remarks>
        ///    <para>Many media players and taggers incorrectly treat
        ///    Latin-1 fields as "default encoding" fields. As such, a
        ///    tag may end up with Windows-1250 encoded text. While this
        ///    problem would be apparent when moving a file from one
        ///    computer to another, it would not be apparent on the
        ///    original machine. By setting this property to <see
        ///    langword="true" />, your program will behave like Windows
        ///    Media Player and others, who read tags with this broken
        ///    behavior.</para>
        ///    <para>Please note that TagLib# stores tag data in Unicode
        ///    formats at every possible instance to avoid these
        ///    problems in tags it has written.</para>
        /// </remarks>
        public static bool UseBrokenLatin1Behavior {
            get {return use_broken_latin1;}
            set {use_broken_latin1 = value;}
        }

However, there's currently no way for the user to set this option. I guess i could be added to advanced config in CUETools, although i agree with the authors of the above comment that it's not a desired behaviour.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 12 2014, 01:43
Post #2491





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (plugs13amp @ May 11 2014, 03:40) *
The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file

I just uploaded a new build of 2.1.5. Can you please check it has the same problem? I just removed CSScriptLibrary.v1.1.dll (which was probably the one causing the false-positive) from the package. So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.

This post has been edited by Gregory S. Chudov: May 12 2014, 01:54


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
mjb2006
post May 12 2014, 02:47
Post #2492





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



The download link at http://cuetools.net/wiki/CUETools_Download still points to the old version (the build from 2013-04-21).

This post has been edited by mjb2006: May 12 2014, 02:47
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 12 2014, 03:31
Post #2493





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (mjb2006 @ May 11 2014, 20:47) *
The download link at http://cuetools.net/wiki/CUETools_Download still points to the old version (the build from 2013-04-21).

Oops. Should be fixed in a few minutes, sorry about that


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
korth
post May 12 2014, 04:43
Post #2494





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



QUOTE (Gregory S. Chudov @ May 12 2014, 00:43) *
So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.

I planned to play with them but I can do that with an older version. Just to clarify, included scripts like 'repair' will still work but new user written custom scripts won't be possible. (Note: I've tested 'repair' and 'fix offset' already to verify they work).

This post has been edited by korth: May 12 2014, 04:46


--------------------
korth
Go to the top of the page
+Quote Post
plugs13amp
post May 12 2014, 11:50
Post #2495





Group: Members
Posts: 4
Joined: 11-April 14
Member No.: 115467



QUOTE (Gregory S. Chudov @ May 12 2014, 01:43) *
QUOTE (plugs13amp @ May 11 2014, 03:40) *
The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file

I just uploaded a new build of 2.1.5. Can you please check it has the same problem? I just removed CSScriptLibrary.v1.1.dll (which was probably the one causing the false-positive) from the package. So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.


Yes, thats fixed it. maybe Avast will get round to sorting it one day and you can re-instate the custom scripts support, you shouldn't have had to remove functionality from your product to get round someone elses problems. If they do fix it, I'll report back.

Thanks for responding so quickly, its a great little app
Go to the top of the page
+Quote Post
korth
post May 12 2014, 15:41
Post #2496





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



Confirming that the CUETools disappearing 'offset' box issue (this post, this post, or bug tracker) when changing the text size (DPI) setting in Windows appears to be fixed in the latest build of 2.1.5 dated May 11, 2014. Tested on Win7x64 at 125% (120ppi) & 150% (144ppi).

This post has been edited by korth: May 12 2014, 15:43


--------------------
korth
Go to the top of the page
+Quote Post
Wombat
post May 12 2014, 17:24
Post #2497





Group: Members
Posts: 1037
Joined: 7-October 01
Member No.: 235



COMMENT from CUE written to tag 'bug' still there!
Go to the top of the page
+Quote Post
thores
post May 26 2014, 16:21
Post #2498





Group: Members
Posts: 3
Joined: 26-May 14
Member No.: 116226



Hi!

I want to convert HDCD to 24 bit with CueTools but the process unfortunately is irreversible. This means I have to keep two versions, 16 bit and 24 bit, since I don't want to waste the accurately ripped files. This will take up twice as much space, and I have far too many HDCD's to make it worthwhile.

Hence, my question is: Isn't there a way to make a small extra file with the data needed to recreate the original file from the 24 bit version? I mean, every single bit of information in the 16 bit file is also present in the 24 bit file, only at a different location.

I assume that a program like this does not yet exist, since CueTools says the process is irreversible.

Obviously I have no programming skill, so maybe someone is willing to explain if this is possible to do?

Thore
Go to the top of the page
+Quote Post
d125q
post May 26 2014, 17:03
Post #2499





Group: Members
Posts: 64
Joined: 4-May 13
Member No.: 107966



QUOTE (thores @ May 26 2014, 16:21) *
Hi!

I want to convert HDCD to 24 bit with CueTools but the process unfortunately is irreversible. This means I have to keep two versions, 16 bit and 24 bit, since I don't want to waste the accurately ripped files. This will take up twice as much space, and I have far too many HDCD's to make it worthwhile.

Hence, my question is: Isn't there a way to make a small extra file with the data needed to recreate the original file from the 24 bit version? I mean, every single bit of information in the 16 bit file is also present in the 24 bit file, only at a different location.

I assume that a program like this does not yet exist, since CueTools says the process is irreversible.

Obviously I have no programming skill, so maybe someone is willing to explain if this is possible to do?

Thore

Try using foobar2000 and foo_hdcd to decode your HDCD material on-the-fly. This means that you won't need to convert to 24-bit at all.
Go to the top of the page
+Quote Post
Wombat
post May 26 2014, 17:06
Post #2500





Group: Members
Posts: 1037
Joined: 7-October 01
Member No.: 235



You may spend some time checking how the HDCD decodes. Many only shift bit 1-16 to 2-17 without changing the audio and leave the upper 6dB unused. These are surely not worth to keep at higher bitrate.
Go to the top of the page
+Quote Post

103 Pages V  « < 98 99 100 101 102 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th September 2014 - 14:04