Whenever I try to rip a CD using CueRipper, I always get an error stating that there were 15 suspicious sectors, although the rip has been confirmed with Accurip; for an example, the CD I've just tried produced the following Accurip file:

- 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?

- 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.

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.

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 -).

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.

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 .

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.

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

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.

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

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.

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.

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.

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.

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-082af4ba45c1You 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.

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 -).

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.