IPB

Welcome Guest ( Log In | Register )

100 Pages V  « < 94 95 96 97 98 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
evil-doer
post Jul 26 2013, 18:55
Post #2376





Group: Members
Posts: 8
Joined: 22-June 13
Member No.: 108777



nope and nope. tried it portable, and also have the folders intact.
Go to the top of the page
+Quote Post
evil-doer
post Jul 29 2013, 20:53
Post #2377





Group: Members
Posts: 8
Joined: 22-June 13
Member No.: 108777



any other ideas i can try? any way to debug this problem? ill try anything!

thanks.
Go to the top of the page
+Quote Post
Wombat
post Jul 29 2013, 21:15
Post #2378





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



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

This post has been edited by Wombat: Jul 29 2013, 21:18
Go to the top of the page
+Quote Post
evil-doer
post Jul 30 2013, 01:46
Post #2379





Group: Members
Posts: 8
Joined: 22-June 13
Member No.: 108777



QUOTE (Wombat @ Jul 29 2013, 15:15) *
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.
Go to the top of the page
+Quote Post
korth
post Jul 31 2013, 18:01
Post #2380





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



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
Go to the top of the page
+Quote Post
ligerpants
post Jul 31 2013, 20:54
Post #2381





Group: Members
Posts: 5
Joined: 23-May 13
From: New York, NY
Member No.: 108287



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.

This post has been edited by ligerpants: Jul 31 2013, 21:01
Go to the top of the page
+Quote Post
korth
post Jul 31 2013, 21:55
Post #2382





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



Try %year% for the album Date and %releasedate% for the Release Date

This post has been edited by korth: Jul 31 2013, 21:57


--------------------
korth
Go to the top of the page
+Quote Post
msmucr
post Jul 31 2013, 23:45
Post #2383





Group: Members
Posts: 2
Joined: 31-July 13
Member No.: 109395



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

This post has been edited by msmucr: Jul 31 2013, 23:46
Go to the top of the page
+Quote Post
db1989
post Jul 31 2013, 23:55
Post #2384





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



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.
Go to the top of the page
+Quote Post
ligerpants
post Aug 1 2013, 05:05
Post #2385





Group: Members
Posts: 5
Joined: 23-May 13
From: New York, NY
Member No.: 108287



QUOTE (korth @ Jul 31 2013, 15:55) *
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. blink.gif
Go to the top of the page
+Quote Post
msmucr
post Aug 2 2013, 00:52
Post #2386





Group: Members
Posts: 2
Joined: 31-July 13
Member No.: 109395



QUOTE (db1989 @ Jul 31 2013, 23:55) *
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
Go to the top of the page
+Quote Post
shaboo
post Aug 4 2013, 01:41
Post #2387





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



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.
Go to the top of the page
+Quote Post
shaboo
post Aug 4 2013, 18:27
Post #2388





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



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 ...
Go to the top of the page
+Quote Post
somian
post Aug 18 2013, 05:49
Post #2389





Group: Members
Posts: 1
Joined: 8-March 10
Member No.: 78844



Hello - and biggrin.gif 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? unsure.gif

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

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]
Go to the top of the page
+Quote Post
shaboo
post Aug 31 2013, 13:40
Post #2390





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



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.

This post has been edited by shaboo: Aug 31 2013, 13:59
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Aug 31 2013, 13:54
Post #2391





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



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.4
Go to the top of the page
+Quote Post
korth
post Aug 31 2013, 14:36
Post #2392





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



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

QUOTE (Gregory S. Chudov @ Aug 19 2012, 12:43) *
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
Go to the top of the page
+Quote Post
shaboo
post Aug 31 2013, 14:39
Post #2393





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



QUOTE (Gregory S. Chudov @ Aug 31 2013, 14:54) *
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.
Go to the top of the page
+Quote Post
shaboo
post Aug 31 2013, 14:49
Post #2394





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



QUOTE (korth @ Aug 31 2013, 15:36) *
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.

QUOTE (korth @ Aug 31 2013, 15:36) *
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.

This post has been edited by shaboo: Aug 31 2013, 14:54
Go to the top of the page
+Quote Post
mjb2006
post Sep 3 2013, 04:18
Post #2395





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



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.

This post has been edited by mjb2006: Sep 3 2013, 04:19
Go to the top of the page
+Quote Post
shaboo
post Sep 13 2013, 13:21
Post #2396





Group: Members
Posts: 11
Joined: 14-May 13
Member No.: 108127



QUOTE (mjb2006 @ Sep 3 2013, 05:18) *
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.
Go to the top of the page
+Quote Post
dannytran1191
post Sep 29 2013, 17:33
Post #2397





Group: Members
Posts: 3
Joined: 20-August 13
Member No.: 109704



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.
Go to the top of the page
+Quote Post
echofu
post Sep 29 2013, 18:15
Post #2398





Group: Members
Posts: 6
Joined: 18-February 10
Member No.: 78257



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.

Go to the top of the page
+Quote Post
korth
post Sep 29 2013, 20:06
Post #2399





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



echofu,
Known issue. See this post or this post in this thread, or the bug tracker.

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

This post has been edited by korth: Sep 29 2013, 21:03


--------------------
korth
Go to the top of the page
+Quote Post
NetRanger
post Oct 22 2013, 13:00
Post #2400





Group: Members
Posts: 55
Joined: 2-November 03
Member No.: 9605



WavPack v4.70 is out. Really hope to see it in v2.1.5
Go to the top of the page
+Quote Post

100 Pages V  « < 94 95 96 97 98 > » 
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 April 2014 - 12:06