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 1894069 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 #2375
any other ideas i can try? any way to debug this problem? ill try anything!

thanks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2376
Do you have Microsoft .NET Framework 2.0 (SP2) and Visual C++ 2008 runtime properly installed like the CUEtools Wiki tells?
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2377
Do you have Microsoft .NET Framework 2.0 (SP2) and Visual C++ 2008 runtime properly installed like the CUEtools Wiki tells?

yes, and the rest of the system is as up to date as physically possible as well.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2378
OK I see a similar problem on my WinXPx64 system but I just have no WMA encoders. All files are present and hashes match the ones on my Win7x64 system (which has the WMA encoders). Don't know if these stopped working or never worked on the WinXPx64 system. evil-doer, if I find anything useful I'll let you know.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2379
Bug report for 2.1.5 CUETools. The %date% template tag shows up literally in the end filename when encoding:

Helium - Pirate Prude (US %date%).tak

It worked in 2.1.4 and earlier. I haven't found any other tags that do this, but I haven't tested any I don't normally use:

%artist%  %releasetype%  %album%  %releasecountry%  %date%

--

EDIT: Also, in the resulting files, the Date tag is truncated from eg. 1994-03-08 to simply 1994.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2380
Try %year% for the album Date and %releasedate% for the Release Date
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2381
Hello,

do you know, if there is any technical reason to not support audio formats other than 44100Hz/16bit in CUETools operations? I searched little bit about that, but found only one older post about that ( http://www.hydrogenaudio.org/forums/index....showtopic=92011 ). Personally, i would be very happy, if it will be supported, mainly due to PS3 rips from SACD edited masters, but also for other general use with Hires files (for instance personally if i need to split something to tracks, it is very easy to write cuesheet). I know, that there are few other possibilities how to handle it, like in foobar or using commandline cuetools and shnsplit, but none is so comfortable (requires additional manual steps) and solid as CUETools.
Higher sample rates and 24bit quantisation should be supported by most lossless codecs. Lossy codecs usually working up to 48kHz, but for instance qaac comes with built-in sample rate converter.. So it is not completely covered to all output formats, but with this on mind, i'm not aware of other limitations.

Aside from this.. anybody else, who will welcome this functionality?

Best regards

Michal

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2382
There is a technical reason in the sense that cuesheets were designed to specify the layout of audio CDs, and audio CDs are always sampled at 44100 Hz and in 16 bits.

Not completely sure, but I seem to recall that Gregory is on the record as saying this limitation is perfectly intended and will remain.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2383
Try %year% for the album Date and %releasedate% for the Release Date


Thanks for the suggestion. On testing, these both also truncate to four digits, and only resolve if I choose Musicbrainz data instead of the cuesheet. Which is odd, because I use embedded cues, and tag with MB data using MB Picard (before embedding) and FB2K both. 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2384
There is a technical reason in the sense that cuesheets were designed to specify the layout of audio CDs, and audio CDs are always sampled at 44100 Hz and in 16 bits.

Not completely sure, but I seem to recall that Gregory is on the record as saying this limitation is perfectly intended and will remain.


Thanks for comment DB,

you're true about original purpose of cuesheets. I was just curious about that, as it evolved to me and could be used also for other things... and i have still preference for using cuesheet to lets say Matroska, despite it limitations (like 1/75s time step).

Best regards

Michal

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2385
Bug Report CUETools Version 2.1.5:

CUETools has a  problem with quotes used in the title of an album.

Ripping a CD with CUERipper and using an album title like

Vintage Gold [3"-CD]

this CD can be ripped and verified with CT/AR databases without any problem.

However, using CUETools for verifying this rip again, doesn't work, because of an "illegal character in path" error.
This is due to the ", used in the album title. I had to remove the " from the album title tags of all tracks to be able
to verify the rip.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2386
It's nice to have the "Preserve HTOA" option in CUERipper, but unfortunately the resulting file (FLAC, in my case) is free from any tags or an embedded artwork.
Is there a reason for this? All tags applying to the regular album tracks, usually also apply to potential HTOA (artwork included), so default behavior should be to include this stuff. I really can't imagine anyone caring about tags/artwork, but leaving a ripped HTOA track completely untagged ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2387
Hello - and  for CUETools -

To try what I describe 3 paragraphs down:

I downloaded the testing / devel  http://www.cuetools.net/install/  ..... CUETools_2.1.5.zip

I run a distro closely tracking Ubuntu 13 with pretty new mono binaries.

I am switching to using Linux. I want to run CUETools on Linux platforms. On several different occasions I have read that CUETools via mono (or Wine, also?) does only support WAVE. I have rips made with CUETools on a Windows system which I have put into the Linux filesystem. These "rips" are done as single flac + separate CUE file. IOW, the source material for convert operations is a flac file with every track in one file, and cue file indexing into the flac file.

Can I use CUETools to convert these "rips" to anything - using mono to run CUETools on GNU/Linux

If not, can I use Wine to get the functionality to convert these "rips" to separate per-track .flac files? 

If none of the above, because no changes have been made in the situation since the last time a forum user reported anything about using mono to run CUETools ...then thanks for reading, and I did not mean to add noise to the forum, and thanks for all the work that goes into CUETools, and thanks for welcoming me to hydrogenaudio.

  somian
[font="Georgia"]Soren Andersen[/font]

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2388
Bug Report CUETools Version 2.1.5:

CUERipper has a problem with "Barcode" tag and "CATALOG" entry in the CUE sheet.

When ripping a CD and entering a value for the "Barcode" tag, this info should be transferred to
the CUE sheet as "CATALOG" entry. However, this doesn't work. Most of the time the "CATALOG"
entry in the CUE sheet will contain some number (supposedly from freedb or a similar source),
but NOT the number that was manually entered under "Barcode".

In addition, besides the LABELNO, the barcode is an important identifier, that is very handy
when trying to exactly identify a release at sites like discogs. If you provide the possibilty to
enter this value during the ripping process, it would be only logical to also store this info in
a tag, and not only in the CUE sheet. Vorbis, for example, provides the generally accepted
EAN/UPN tag for this purpose.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2389
I think it's silently overwritten by a barcode that's read from the CD during gap detection - the cue should reflect the actual CD medium after all.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2390
Slight chance the Barcode entry could revert back to what was retrieved from the db due to this bug

CUERipper currently saves metadata edits only when you start ripping, and reloads it only if the system reports that a drive (not necessarily the currently selected drive) has had a disc ejected or loaded. I don't know what might cause the OS to report this erroneously (never happened to me), but i should probably make CUERipper save metadata when this happens.

I recently experienced this on one disc (and only one disc) using the current 2.1.5 release. The metadata just kept reloading though nothing was happening with the drive. Unfortunately I didn't make a note of which disc it was and I haven't seen this happen since so I can't reproduce it.

Of course if the Barcode field was blank before the manual entry, the 'other number' isn't coming from the retrieved metadata.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2391
I think it's silently overwritten by a barcode that's read from the CD during gap detection - the cue should reflect the actual CD medium after all.


Shouldn't this decision be left to the user? Most of the time, the only barcode that is of any actual meaning, is the one that is printed on the package and serves the purpose to uniquely identify a specific RELEASE of an album (not disc). Using some kind of "secret" barcode (that many users won't even be able to read) in order to identify a DISC (as part of a release), isn't common practice, as usually matrix/runout information is used at this level of identification (which makes perfect sense, as only this information provides a reliable method for identifiying a disc, while the stored barcode doesn't).

I think you'll agree that it doesn't make any sense to give an user the possibility to enter a barcode, that isn't stored in any tag or in the logs, and that, at the only place where it's supposed to appear (in the CUE sheet), is silently overwritten with some kind of secret value, that is not even shown to the user. Usually users know what they are doing when assigning values to tags ...

At least, if you absolutely insist on using the disc-stored barcode, this should be made unmistakably clear to the user by

1) always displaying the disc-stored barcode in the "Barcode" field (instead of displaying some barcode retrieved from freedb or some other metadata source, as these are obviously completely irrelevant to CUERipper), and

2) greying out the "Barcode" field, to make it clear to the user, that the content of this field can't be edited.

However, I think the easiest way would be to simply allow the user to edit this field and store its value in a tag and in the cue sheet.
You can always add some kind of "always use disc-stored barcode" option under extraction and use this as default setting for CUERipper.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2392
Slight chance the Barcode entry could revert back to what was retrieved from the db due to this bug ...


I'm aware of this bug, but the phenomenon I described is a general one, not related to this bug.

Of course if the Barcode field was blank before the manual entry, the 'other number' isn't coming from the retrieved metadata.


Of course not. As we both know now from Gregory's answer, it's coming from the disc itself.
This also explains that, even if some metadata was retrieved and was left unchanged, the value actually used by CUERipper usually doesn't
match this data, which is very confusing.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2393
Well, everyone has different expectations of what should be in the cue sheet and what should be in the tags. I feel that cue sheets shouldn't contain any data that wasn't read from the disc itself. Or there should be a separate cue sheet which has all the external data in it. Also there should be an indication in comments of what was and wasn't scanned for; e.g. I want to know if missing data just wasn't found, or if it wasn't even checked for. Dream on, I guess.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2394
Well, everyone has different expectations of what should be in the cue sheet and what should be in the tags. I feel that cue sheets shouldn't contain any data that wasn't read from the disc itself.


Using REM, you can include arbitrary information in the cue sheet and there's absolutely no reason not to do this, as this doesn't compromise the integrity of any data that was read from the disc itself. Having an album comment or an album replay gain value, it absolutely makes sense to write these values in the cue sheet. If you don't need them, then simply don't use them, but they'll never hurt. You don't need a separate cue sheet for this. In addition, that was not my point. My point was, that, specifically regarding the barcode tag, it doesn't make sense to give an user the possibility to enter a barcode, that isn't stored in any tag or in the logs, and that, at the only place where it's supposed to appear (in the CUE sheet), is silently overwritten with some kind of secret value, that is not even shown to the user.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2395
Can you please add a way to manually select CD tracks for CueRipper? Make sure to add a checkbox on top of all the others so we can select/deselect multiple tracks at once. Appreciate it.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2396
Windows DPI Scaling problem with CUETools 2.1.4 (I haven't used any other versions)

when using Larger scale DPI (120) in Windows Vista, the Offset box in the 'extra' section of CUETools is not visible.

resizing or maximizing the window does not help.  the only way I can see and use the Offset box is to change the DPI back to 96 (Default), which makes everything else too small.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2397
echofu,
Known issue. See [a href='index.php?act=findpost&pid=840158']this post[/a] or [a href='index.php?act=findpost&pid=800027']this post[/a] in this thread, or the bug tracker.

[EDIT] I'm using a custom size of 106 DPI (110%) without issue.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2398
WavPack v4.70 is out. Really hope to see it in v2.1.5

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2399
I'm trying to run cuetools on linux using Mono. It starts but complains that flac is not supported. And when I try to go to settings it crashes. Tested on 2.1.4 and 2.1.5. I've found deeper in this thread that people were able to run it. Anybody else having these issues?