Skip to main content

Topic: CUETools versions 1.9.5 through 2.1.5 (current) (Read 1312059 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2475
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.

  • acrox999
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2476
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.


CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2477
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

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2478
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

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2479
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?
  • Last Edit: 03 May, 2014, 01:38:35 PM by nospamorban

  • Zarggg
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2480
What is the full path of the file in question?

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2481
What is the full path of the file in question?


C:\Users\Admin\AppData\Local\Temp

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2482
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.

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2483
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?
  • Last Edit: 04 May, 2014, 03:21:34 PM by ChronoSphere

  • cherry99
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2484
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

           





CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2485
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

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2486
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.

  • cherry99
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2487
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
     

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2488
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

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2489
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: [Select]
        /// <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

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2490
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.
  • Last Edit: 11 May, 2014, 08:54:50 PM by Gregory S. Chudov
CUETools 2.1.4

  • mjb2006
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2491
The download link at http://cuetools.net/wiki/CUETools_Download still points to the old version (the build from 2013-04-21).
  • Last Edit: 11 May, 2014, 09:47:58 PM by mjb2006

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2492
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

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2493
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).
  • Last Edit: 11 May, 2014, 11:46:55 PM by korth
korth

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2494
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

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2495
Confirming that the CUETools disappearing 'offset' box issue ([a href='index.php?act=findpost&pid=800027']this post[/a], [a href='index.php?act=findpost&pid=846177']this post[/a], 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).
  • Last Edit: 12 May, 2014, 10:43:03 AM by korth
korth

  • Wombat
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2496
COMMENT from CUE written to tag 'bug' still there!
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

  • thores
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2497
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

  • d125q
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2498
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.

  • Wombat
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2499
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.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!