Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1894763 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #225
Hi Gregory

Thanks for the new feature - letting input pregaps directly from the interface. I find it very useful, because I have many old rips without cue and log files, so when my rip can't be found in accurate rip database, I try to find it with the most often used pregaps (00:00.32 and 00:00.33).

BTW... are you planning to add similar feature like in TripleFLAC - searching accurate rip db for different pregaps?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #226
I don't want to make Mr Spoon unhappy by putting too much stress on the database.
CUETools 2.1.6

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #228
I checked and the Athlon processor only supports MMX and not SSE. That is probably the issue. Could you build a version of the dll that only uses MMX and post it? It would be easier that modifying the program.

Please try the new build, setting DisableAsm=1 in settings.txt file (located in users\<username>\AppData\Roaming\CUE Tools. AppData might be a hidden folder, and might have a different name under XP)

You're a genius. It worked perfectly!
Glass half full!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #229
You could check musicbrainz or freedb/freedb2 to see if there's a submitted disc that has the same track sizes but a different pregap.

In fact, i do. It already works, but not automaticly yet. If you select 'Freedb lookup' mode 'always' and try to convert, you can see the pregap in freedb entry - notice there's now a column with start offsets for each track. If the start offset for first track in nonzero, you can manually enter that pregap value in the main window.

I will probably somehow automate this process in the next version.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #230
This compiles CUETools_1.9.5a CLI for Linux:

mkbundle2 ArCueDotNet.exe CUETools.Processor.dll taglib-sharp.dll HDCDDotNet.dll CUETools.Ripper.SCSI.dll CUETools.Codecs.dll CUETools.AccurateRip.dll CUETools.CDImage.dll UnRarDotNet.dll ICSharpCode.SharpZipLib.dll Bwg.Scsi.dll Bwg.Logging.dll Freedb.dll MusicBrainz.dll CUETools.Codecs.LossyWAV.dll CUETools.Codecs.ALAC.dll CUETools.Codecs.FLAC.dll CUETools.Codecs.WavPack.dll CUETools.Codecs.APE.dll CUETools.Codecs.TTA.dll -o ArCueTools


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #231
I've been conducting regular checks of my 1700-odd rips against the AR database ever since the arcue scripts and executables became available, and have just begun using CUETools for this purpose - it's a very handy tool!!

I was surprised to find that the AR results from my latest check (7-8 March 09) were EXACTLY the same as those from a month ago, with the exception of one disc (Radiohead's "OK Computer"). I used to get significant jumps in the confidence levels, even if my checks were weeks apart. Has the AR database been closed for submissions, is CUETools querying it differently from the arcue script, or did I miss something altogehter?


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #232
CUETools is doing it exactly the same way as arcue, i.e. it currently has no cache.
As far as i know, submissions to the database are not immediate.
Looks like it's updated every month or two.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #233
Hi everyone,
I have a request: could you plz add the support of .ogg in the filename corrector.

I know it may sound strange at first but let me explain:
I store all my rip as CDImage.flac+cue, soon my HDD will be full again & I have already 6 HDD (2,5TO), so I will not buy another HDD.
I know it is not the good storage strategy as each time I buy a new HDD I promise myself this is the last one ...
For storage, I like using CDImage+cue with F2K on my computer. I only use separated files for my personnal "Best Of" folder with my favorite songs which I use both on my computer & my DAP.
But If I really favor CDImage+cue over splitted files for archive, I don't care anymore if the image is lossless or lossy. So I plan mix both: lossless CDImage for my favorite albums & lossy CDImage for the rest of my collection in order to save space. I don't want to be forced to used joined files with lossless & splitted files with lossy like everyone is doing. I want to use CDImage for both lossless & lossy.

For a long time I have considered using lossyflac+cue as I could split & join it as I wanted & didn't needed to fix the cue manually (lossyflac works with cuetools as it's flac), but I finally changed my mind when I realized that I would never need to rejoin my splitted vorbis files because I would always keep my lossy CDImage.ogg+cue anyway. So I only needed perfect splitting.
So I decided to use aotuv at q4 as CDImage & split for my DAP with MusiCutter(vcut), which cuts CDImage.ogg with a cue like a charm. (Sample Accurate & keeps Vorbis's Vendor String)
My only problem now is that if I encode 100 CDImage.flac to CDImage.ogg, I must edit manually each .cue to fix the extension which is a pain.
I am almost certain that this is a very easy feature to add, it is just that nobody except me uses this strategy so far. FUD is usually enough to prevent people from doing what I intend to do.

So could you plz allow the filename corrector to support lossy CDImage plz (specially vorbis),
If you don't want to allow it by default just make an option for it.

Except the fact that this is not an usual way of storage, there is no reason not to allow it, CDImage.ogg plays just as well as CDImage.flac in F2K & it split losslessly with MusiCutter(vcut) so you can always get your tracks out of it. Almost as if you ripped them as separate ogg in the the first place. This storage strategy only needs a batch extension corrector to be 100% easy.

I hope you will understand my point of view & that you are not one of those purist who will tell me that I create dirty or non-compliant .cue with my CDImage.ogg thing. Thks.

Edit1: Question
I tried another tool called InTheCUE for this job which worked but was also changing WAVE to OGG inside the .cue, which broke the playback in F2K, so I ask the question as I guess you are a cue specialist, what is valid with CDImage.ogg+cue:
FILE "CDImage.ogg" WAVE which work in F2K or FILE "CDImage.ogg" OGG which is broken in F2K ???
I guess the guy who created the tool used FILE "CDImage.ogg" OGG as an imitation of FILE "CDImage.mp3" MP3 ... but I don't know if he was right, as F2K/MusiCutter don't work when you do that.

Edit2:
Indeed I don't ask for full support which would be stupid, just support within the filename corrector (& even optionnal if you wish).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #234
if i understand you right:
when you are converting with foobar from flac to ogg image (generate multi-track file) then you'll get ogg image with all the cue info stored in vorbis comment
also if you need separate cue file you can use foo_cuesheet_creator and output it

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #235
absolutly not, I don't used embedded cuesheet at all ... I don't know why but I was pretty sure that I would be misunderstood ... I only want the filename corrector to find my CDImage.ogg, last time I tried to fix the broken link between a .cue & a .ogg, cuetools couldn't locate my lossy CDImage.ogg as ogg wasn't supported I guess.

in fact I am convinced that much more people would use lossy CDImage if the support for it was better ... I think anyone using lossless CDImage+cue because they don't like to tag&rename hundred of files, would naturally come to lossy CDImage+cue sooner or later ... it's a question of time (& money) before they run out of storage space.
It's only because sample accurate & clean splitting is not possible with every format/splitter that people fear that they will lose data or get corrupted files by doing it my way. With vorbis & the right tools, it really becomes an idiot fear. For a long time I was myself frighten of doing it this way ... I was telling myself I could not be right alone when everyone was doing it with splitted files ... I read HA since what ... 6 years maybe more, I have tested all codecs & all splitters around, now all the FUD is gone & I still like the idea of using CDImage.ogg+cue ... the only thing I need is a bach filename corrector ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #236
My only problem now is that if I encode 100 CDImage.flac to CDImage.ogg, I must edit manually each .cue to fix the extension which is a pain.

Since 1.9.5, you can encode flac to ogg with CUETools, producing correct cue sheets from the start.
Nevertheless, i'll probably add lossy formats support to filename corrector.

I tried another tool called InTheCUE for this job which worked but was also changing WAVE to OGG inside the .cue, which broke the playback in F2K, so I ask the question as I guess you are a cue specialist, what is valid with CDImage.ogg+cue:
FILE "CDImage.ogg" WAVE which work in F2K or FILE "CDImage.ogg" OGG which is broken in F2K ???

Both are not valid from purist point of view, but WAVE is a lot better supported.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #237
Quote Gregory S. Chudov:
"Nevertheless, i'll probably add lossy formats support to filename corrector."
Thks a lot !!! I'll save a lot of time  I have high hopes.

PS: I promise I will not use it to encode my Pink Floyd collection to lossy


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #239
There's no need for him to repeat himself.  He's already said this is the case.

http://www.google.com/search?hl=en&saf...amp;btnG=Search
http://forum.dbpoweramp.com/showthread.php?t=16475

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #240
I hope you will understand my point of view & that you are not one of those purist who will tell me that I create dirty or non-compliant .cue with my CDImage.ogg thing. Thks.


OGG Vorbis supports chaining (chapters). You don't need a cue sheet unless you have a mad desire to store two files per CD. 

foobar2000 reads and writes chained OGGs natively. If you open a chained OGG it will appear as if you loaded separate tracks or via a cue sheet. You can also take any separate OGGs you may have right now and make them chained by simply concatenating them together with any software that allows pure file joining. Each track has its own set of tags.

If you need to pull out an individual track from a chained OGG, get oggsplit from rarewares.org and drop the chained OGG onto the oggplit.exe

When converting to chained OGG in foobar2000 you need to check "merge all tracks into one output file" in the converter. I've done the same thing you mention with thousands of OGGs, and not a single cue sheet has been necessary. I find it spectaculary convenient with box sets. On the outside a 4-CD box set appears as one lone OGG. Loaded in foobar2000, it looks as though I loaded all 4 CDs worth of tracks. 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #241
Thks. I know about chained OGG, some joiner I tested created these kind of files. I just don't like it. As I use separate cue for lossless CDImage, I just want to go the same way for lossy CDImage. Only by habbit & for homogeneity. For the same reason I don't like embedded cue, I don't like chained vorbis. It fells unatural to me ... over complicated for no gain.
As you said, I do have a mad desire to store two files per CD ... even 3 as I always keep the EAC log.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #243
I have  feature proposal: skip transconding if (encoder and encoder version and quality settings) or (encoder and quality settings) of the file are identical to the ones set in CUE Tools. Maybe choosing which one of these three must be matched is necessary, too, in order to give users a maximum of flexability. And of course, being able to transcode no matter what should still be possible.

For example: wvunpack -ss could give this info "modalities: lossless, very high, extra-3". Now if CUE Tools is set to encode with very high and extra mode 3, the encoding should be skipped, if the user wants it to.

Reason is obvious: if you have already transcoded some audio files to your new desired codec and quality setting then skipping these files will speed up batch transconding the whole rest of your collection.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #245
Please, try out the new UI. Would be nice to see some screenshots from XP, if it works:), because i only tested it on Vista.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #246
I like it. 
(I'm on Vista here... classical skin, however.)
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #247
 ... I didn't test but I am not sure that I like the change. I will have to test. I used to do a lot of right clic "search music folder for .cue" then "drag & drop" lots of .cue.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #248
tuxman: i assume this means i haven't broken the localization too much?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #249
Of course you have.
(Would you mind changing the strings in my translations accordingly, like adding new strings as "<value />", when updating everything? It would surely help me to keep an overview...)

Just working on an update.
audiophile // flac & wavpack, mostly // using too many audio players