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 1893813 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 #1800
Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1801
Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1802
Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?


I'm using EAC 1.0 beta 3; that's the latest version right?

The '15 suspicious errors' report happens every time with CueRipper for *any* CD that I attempt with it.

Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.


No, I've tried Secure and Paranoid modes in CueRipper and apart from exponentially increasing the time taken to rip it always produces the same result

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1803
Are the errors always right at the end of the disc? They are for the log you posted. 

This is why the rip passes accuraterip.  It should also pass CTDB. I'm not sure what the CTDB issues are with this disc.  Do you usually get a good CTDB result?

I think it is the drive, it seems to be like when a drive that cannot overread is asked to (although CueTools does not overread).  This is a complete speculation though.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1804
This is why the rip passes accuraterip.
I know the logs are hard to read as posted. The (possible) error in the CUERipper log as posted occurred between 31 & 32 seconds from the end of the disc. Too far to pass accuraterip on an offset issue. I said possible error because the CRC32s are the same in both logs and the EAC log had no errors reported.
Quote
it seems to be like when a drive that cannot overread is asked to
It does (sort of) resemble the error that occurs when overread is incorrectly enabled in EAC.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1805
Yes, I was looking at Differs in 710 samples @58:26:43-58:26:44, rather than Suspicious position 0:57:54

Odd.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1806
Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1807
any chance of having this tool natively on linux

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1808
Depends. As it is written in C#, you'd need the Mono framework anyway.
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1809
Well, it's written in C# and i have no plans to rewrite it in any other language, so if you don't count mono as 'natively', then the answer is no. What i was considering to do, but haven't found the time, is to at least test it on linux before releasing each version, and maybe create a separate download where it's bundled with mono libs using mkbundle, but i'm not sure how will plugins work in this scenario.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1810
I need help to decide on tag mapping in CUETools.
CTDB metadata contains at least three useful pieces of data that aren't currently written as tags. Those are Release Date, Label and Catalog#.
When using FLAC, i was planning on storing them as "RELEASEDATE", "LABEL" and "LABELNO".
According to http://sublevelseven.com/resources/1/, those should map to "TDRL", "labl"  and "cat#" in mp4, and to "TDRL", "TPUB" and ?nothing in mp3.
But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.
Also no idea how to store release country and disc name .
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1811
Quote
But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.
Isn't "ALBUM ARTIST" unique to foobar2k (and CUETools)?

I'd say "RELEASEDATE",  "PUBLISHER", and "CATALOG" but don't see why foobar2k's "RELEASE DATE" or your choice of "LABEL" and "LABELNO" wouldn't work also.
Quote
Also no idea how to store release country and disc name.
You're getting into "User defined" or "TXXX" territory with "Release Country" and "Disc Name". I'd say "COUNTRY" or "RELEASECOUNTRY" and "DISCNAME"

But this is just my 2 cents. Additional discussion welcome.

korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1812
Here are some facts regarding LABEL / PUBLISHER and foobar2000:
-For VorbisComment (FLAC), foobar2000 prefers PUBLISHER over ORGANIZATION (Label). It shows values from those fields only as PUBLISHER in the properties of a file.
-foobar2000 can not read multiple values in the TPUB (PUBLISHER) field in ID3v2.

So, if you want to base your tags on foobar2000, I'd go with PUBLISHER for VorbisComment. I don't know if you need multiple values for ID3v2, but if you do, I'd use a custom TXXX frame. If not, TPUB would work fine.

I would also use TYER (ID3v2.3) / TDRC (ID3v2.4) instead of TDRL for the release date. As far as I know, the usage of TYER/TDRC is vast compared to TDRL, which is very rarely used. DATE for VorbisComment.

As for the other tags, personally I'm using the custom tags CATALOG NUMBER (except CATALOG for APEv2 and CATALOG_NUMBER for Matroska, which are specified), DISCNAME and RELEASE LOCATION.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1813
Thank you. One clarification: i mentioned TDRL, because i want to store release date, as opposed to recording date or original release date, which is usually stored as TYER/TDRC. For example, the latest remaster of Pink Floyd's DSotM would have TDRC=1973 and TDRL=2011. Although according to spec, TDRL is also supposed to store original release date
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1814
Yes, I know. I wanted to use TDRL at first too, but everyone's using TYER/TDRC for release date (even though it's actually recording date), so for compatibility, I went with it, too. It's kind of a mess.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1815
Both discogs & muscibrainz return two dates, and i already use TYER for recording/original release date, so i have to use something different for actual release date in case of remastered albums. If i were to use TYER for actual release date, this would only lead to question  where to store original release date... TORY isn't well used either. What's more importantly, all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release. And for those who still want to keep track of remasters, TDRL will probably have to do.

Some news about release country: TagLib has MusicBrainzReleaseCountry field, which used "RELEASECOUNTRY" for VorbisComment and APEv2, and TXXX MusicBrainz Album Release Country for mpeg... They seem to use http://wiki.musicbrainz.org/PicardQt/TagMapping

This document also recommends DISCSUBTITLE/TSST for disc name.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1816
Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release.

Not that I have access to very many people's collections to verify, but from what I've seen, it's quite rare to have more than one date in tags: the one date provided is nearly always the actual release date (year alone, usually), as that's all that the metadata sources tend to provide. The situation is the same in the digital releases I've purchased.

I do prefer my TYER to be the original release date, so I make that change and then put the remaster/compilation date in prose in COMM because I don't know what else to do (in foobar2000). I think most people don't even bother; if the music is from 1977 but the reissue/remaster/compilation came out in 2008, probably the TYER is already set to 2008, and they just leave it as-is.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1817
Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.
I'm talking about musicbrainz/discogs data as returned by CTDB, which provides both dates.

I do prefer my TYER to be the original release date

Exactly. So i think CUETools should do the same, and store remaster date in TDRL.
We all know that the world of tag mapping is in a complete mess, but something has to be done, we can't just give up
In the last few days i've read about a dozen different tag mapping documents from various software vendors, and it's given me a headache.
They cannot agree on anything. So i guess i'll just have to use my own judgement in each case and at least try not to create new names for the same entities.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1818
Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.

Sort-of, but not exactly. The year reported in the Discogs master release is just the earliest year from among the actual release dates of the releases in the set. For albums and singles, this can be safely interpreted as the original release date, and usually it works for the songs on the release. But this interpretation fails for most compilations, or any other album on which there are songs culled from prior years. On those types of releases, a given song's original release date is almost never the same as the release date of any edition of the compilation. So if you're tagging individual tracks, there's no easy way to use Discogs data to get actual original release dates for each song, at least not without some creative use of the search engine.

I don't recall what MusicBrainz does, but I think it's the same kind of situation.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1819
In musicbrainz you can actually find the first release date of a given recording, even if it was released in different release groups.
Each track of each release has a link to a recording, for example here is 'The End' by 'The Doors': http://musicbrainz.org/recording/1423fcd8-...75-082af4ba45c1
You can easily see that the original release date for this recording is 1967-01-04, and you can get to this data from any compilation release.
But CTDB currently doesn't return this data, i'm not sure how relevant it is.

Anyways, this would probably be a third tag  For example, a track originally released in in 1967, included in 2001 remaster of 1995 compilation could have TDOR=1967, TYER=1995, TDRL=2001.
Putting individual track release years in TYER could lead to strange behavior in many applications, because the tracks from this compilation could end up in different folders, or in different groups in the playlist.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1820
Gregory, do you have a possible explanation of this:

Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1821
Sorry, i haven't got around to this yet.

UPD: tried to reproduce it, but couldn't. In theory this can only happen if takc.exe crashes on startup.
foobar2000 uses foo_input_tak.dll instead of takc.exe, so it's not affected.
I wanted to switch to TAK SDK in CUETools, but it only provides 32-bit dll.
And frankly, i don't want to waste any time on a codec for which there's no open-source decoder.
CUETools 2.1.6


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1823
there seems to be a bug in the multi select browser when pressing f5 to refresh. although the "local db" node is present, it cannot be expanded to view anything and it takes a restart to work again.

edit: using + and * keyboard shortcuts around my numpad works but i'm pretty sure it could be done with the mouse before.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1824
I think it can be expanded - just select it and press right arrow on the keyboard. But i'll fix it of course
CUETools 2.1.6