I am getting this error, but I hope it is due to the fact that I have an old version of Mono in my Debian Squeeze system:

CODE

** (CUERipper.exe:5432): WARNING **: The following assembly referenced from /home/manuel/Programas/CUETools/CUERipper.exe could not be loaded: Assembly: System.Deployment (assemblyref_index=10) Version: 2.0.0.0 Public Key: b03f5f7f11d50a3aThe assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/manuel/Programas/CUETools/).

** (CUERipper.exe:5432): WARNING **: Could not load file or assembly 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.File name: 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' at CUERipper.Program.Main () [0x00000] in <filename unknown>:0

CUERipper does embed the CUE sheet when ripping to a single-file flac image and creates a separate CUE sheet file.The "Version" tag is not currently supported.

CUERipper embeds the cuesheet as a Vorbis comment tag. However, FLAC also has a separate CUE sheet metadata tag specifically for single-file FLAC images. The tool I use to manage FLAC images, FLACtag needs the cuesheet information stored in that metadata tag to function effectively.

Would it be possible for CUERipper to support that metadata tag directly, or is there some way to cause CUERipper to execute a command with templated arguments so I can do it myself?

I couldn't duplicate with similar files but I don't have that particular disc. Did you try more than once to rule out a database glitch? Did you try dragging just the cue file instead of the whole folder? Were the AccurateRip ID's in both accurip files the same? (You should have both accurip files now that you're using %unique% in the log format). CTDB says AccurateRip ID: 000d3e3d-005bfdc4-700e2609 with data track length of 19:47.68. Without the data track it would have a different lookup ID ending in 6108ea08 (I don't have my script handy to calculate the first two sections).

Edit: BTW, if the disc was ripped with the proper read offset there's no need to fix the offset to match some other pressing in the database.

Doing encoding, in case that some files already exist, CUETools asks a question. If I answer "Yes" files will be owerwritten. If "No" - the whole operation will not start.So, if I prefer to keep my file (for example, "folder.jpg"), it is impossible at the time.

I think, there should be a normal behavior: Yes - overwrites files, No - keeps them untouched, Cancel - cancels the started operation.

The rip log is EAC-style with TOC showing there are 8 audio tracks plus the CD-Extra data track.

On verify, CUETools will parse the rip log file and adjust the AccurateRip ID to include the CD-Extra data track [000d3e3d-005bfdc4-700e2609].

Now let's say you decided to rename the accurip log file to end in .log and have CUETools set to write that file in the source folder on verify.

On verify, CUETools will parse the rip log file, adjust the AccurateRip ID to include the CD-Extra data track and write the similarly named log file to the source folder.

On encode, CUETools will see two similarly named log files and not know which one to use. If the INPUT were set to Folder Browser mode at file level, CUETools would display a popup window allowing you to choose which log file to use. In batch modes like Drag'n'drop however, popups are disabled so you cannot choose.

CUETools would not include the CD-Extra data track and calculate a different AccurateRip ID [000BB5B0-004E30CF-6108EA08] (if my math is correct, I calculated by hand).

Looks like cuetools.net and db.cuetools.net are both hosted on the same server/IP, probably on Amazon EC2. It doesn't look like there are any general EC2 outages, but the server itself seems to be down, it isn't answering to pings.

Thanks to everyone who tried to reach me. It turns out, that when the instance became unreachable Amazon sent me a letter: "Dear Amazon EC2 Customer, One or more of your Amazon EC2 instances in the us-east-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2012-10-02."Still investigating what it meant and how it happened. Anyway, relaunching the instance solved the problem. Sorry that it took so long, i was sleeping

UPD: turns out this was a hardware failure. Turns out it can still happen in the cloud I am a bit upset with Amazon that they don't provide the option to restart the instances automatically in such cases.

I like CUERipper, especially as it can rip most CDs very quickly with little wear on my optical drive in Burst mode and verify them with AccurateRip or correct small errors via CTDB and it can handle HTOA. If that fails to indicate a secure rip, or we can see in advance that the disc isn't in AR or CTDB, secure mode is also available for peace of mind.

As I've mentioned before I'd quite like a ripper that will detect and decode HDCD discs if I come across them, and ideally detect and correct those rare early PRE-emphasised CDs with non-flat EQ, which I don't think I've ever played. (I don't know whether CUETools can deal with PRE-emphasis, but hope it may be noted in CUEsheets if nothing else). Wikipedia suggests that only a few thousand HDCDs are available, so it represents a small proportion of CDs.

I don't really believe any quality claims that HDCD would be audibly better than the same content if it had been mastered to flat 16-bit PCM (or for that matter, less than 16-bit, as I'm quite happy with lossyWAV -5), so I'm mostly interested in features that might be audible, such as reversing the baked-in peak-limiting, known as peak extension (though I'm not sure I could ABX it once level-matched, but I'd rather correct for it if I can, especially as I might wish to discard the LSBs that signal HDCD is present by using lossyWAV or other lossy rather than lossless). If it turns out not to be possible I won't lose sleep over it and will just put up with undecoded HDCD, which I suspect will be pretty darned transparent and enjoyable to listen to.

I've now been able to test a HDCD pretty thoroughly to see if I can find suitable settings in the undocumented, and therefore potentially unimplemented areas of settings.txt

In short, I think I'm unable to do so...

...unless I accept the sonically transparent idea (for a committed Replay Gain user, that is) of allowing my ripper to do what an HDCD-compliant player does to redbook CDs, and bit-shift all my audio by one-bit to the right, halving its represented amplitude (easily fixed with a volume control or ReplayGain) and turning it into identical 16-bit audio in a 24-bit wrapper, where the lowest 7 bits and the highest bit will be zero padding. These 8 bits of padding will be zero unless HDCD is activated (may then use the MSB to reverse the soft-limiter and 3 bits below the normal LSB if low signal level extension is activated.

This realignment into a 24-bit wrapper has negligible bitrate penalty (a few kbps perhaps) in most lossless encoders (those that are compatible with lossyWAV - a notable exception being ALAC, which comes in over 50% higher bitrate than FLAC) and this gives a minor bitrate advantage to lossyFLAC (which no longer worries about clipping on positive peaks as it can go beyond the new peak of +0.500 within the allowed rounding error calculated by the noise-floor algorithm).

In essence this wouldn't change my workflow as someone who uses ReplayGain and usually bakes Album Gain into my lossy encodes via foobar2000 converter (or my ALAC encodes, which I can force to 16-bit, and usually do, when exporting my backing-track edits for a group's on-stage iPad).

A full requote from the original post as this was a while ago, before I run through my findings:

QUOTE (korth @ Jun 30 2012, 02:01)

Still waiting for Grigory to chime in for your first question.In the meantime, the config is in %appdata%\CUERipper\settings.txtDefault should be:DetectHDCD=1Wait750FramesForHDCD=1DecodeHDCD=0LossyWAVQuality=5DecodeHDCDToLossyWAV16=0DecodeHDCDTo24bit=1Which are the same as CUETools Advanced Settings: 0=unchecked; 1=checked.I honestly haven't tried changing to DecodeHDCD=1 to see if it enables the next 3 settings in CUERipper.

I found an HDCD to test that my cousin left when emigrating, which utilises peak extension at least on the first three tracks (Album peak 0.555992 in lossless after HDCD decoding, when it would be no more than 0.50 without peak-extension)

Although my version is labelled The Essential Alabama and appears to be a USA release through RCA, BMG & LegacyRecordings.com, it was formerly available as Alabama - For The Record and shows up under that title in CUEripper's metadata queries.

I first took a plain rip in CUERipper 2.1.2 and used CUEtools 2.1.2a to convert to 24bit lossless, which worked fine and verified OK in AccurateRip and CTDB. (I know these are now outdated, but the website was down when I started this test, so haven't updated to 2.1.4 on this PC unlike another PC I use in another location)

I then decided to modify %appdata%\CUERipper\settings.txt for various rips and copy the appropriate version of %appdata%\CUERipper\settings.txt into the folder containing that rip so I knew exactly which settings I'd set before restarting CUERipper.

I used a number of other variations in %appdata%\CUERipper\settings.txt some of which remained 16-bit and didn't decode HDCD depending on the DecodeHDCD setting, some became .20bit.20bit.flac files and some .24bit.24bit.flac files the latter depending on the DecodeHDCDTo24bit setting.

I bit-compared the entire album image at 20bit.flac versus 24bit.flac in foobar2000 Utilities/Bit Compare and no differences were found, though there were compatibility problems with 20-bit FLACs in lossyWAV - see below - so it's probably best to work with 24-bit versions, where the 4 LSBs are all zeroed:

CODE

All tracks decoded fine, no differences found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 1"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 1No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 2"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 2No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 3"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 3No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 4"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 4No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 5"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 5No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 6"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 6No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 7"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 7No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 8"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 8No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 9"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 9No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 10"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 10No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 11"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 11No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 12"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 12No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 13"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 13No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 14"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 14No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 15"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 15No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 16"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 16No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 17"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 17No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 18"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 18No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 19"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 19No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 20"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 20No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 21"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 21No differences in decoded data found.

Comparing:"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama - For The Record.20bit.20bit.flac" / index: 22"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 22No differences in decoded data found.

CUEripper always rips to lossless or lossy as selected by the main ripping dialogues regardless of the settings line DecodeHDCDtoLossyWAV16=1 which I presume is ignored at the moment.

The following settings.txt entries (I'm just quoting the relevant lines) resulted in a successful 20bit decode and lossless rip but I was unable to rip to lossyFLAC using these settings - an error message indicated that presumably 20-bit data wasn't compatible with the lossyWAV library in CUERipper/CUETools, while I found that 24-bit was fine:

24-bit files with the 4 LSBs padded to zero, compress to the same size/bitrate as 20-bit files thanks to the unused bit feature of FLAC that's also exploited more creatively by lossyWAV. Those few encoders such as ALAC that don't work with lossyWAV inflate the bitrate greatly (about 40-50%, I believe). My FLAC bitrates were around 1046kbps for 20-bit or 24-bit decoded HDCD files.

The following settings were suitable to rip to lossyFLAC (based on 24-bit files) by selecting the lossyFLAC options in the CUERipper pull-down menus.

The resulting lossyFLAC (at quality 5, standard) came out to 463kbps (versus 1046kbps for lossless decoded, and 460kbps for the un-decoded 16-bit rip - obtained using DecodeHDCD=0 and passed through lossyWAV)

I tried these settings in Image and Track modes with the same results. I was also reassured to note that the whole CD was decoded at the HDCD gain (-6.02 dB, I believe) even though peak extensions didn't appear to be used in tracks 4 to 22, thereby preserving Album Gain's inter-track differences.

The settings in the above CODE snippet will produce lossless 24-bit HDCD decodes if I select lossless and lossyWAV output based on those 24-bit decodes if I select lossyWAV without inducing error messages or incompatibilities in software that dislikes 20-bit audio.

For non HDCD discs, they throw an "Exception: HDCD not detected" and don't rip.

I tried DetectHDCD=0 and it then ripped a non HDCD disc fine, but only ripped my HDCD disc to 16-bit non-decoded (460kbps lossyWAV)

I also tried DetectHDCD=1 and Wait750FramesForHDCD=0, which worked fine for the HDCD, but decoded a non HDCD (Lyle Lovett - Step Inside This House) as if it were HDCD, resulting in 6.02 dB higher Track Gain for Track 01 - Bears, as I'd expect, with a peak of 0.5 exactly (versus 1.0 for the original), so it simply applies the -6.02 dB gain expected of an HDCD-compliant player and doesn't incorrectly peak-extend non-HDCD audio, which seems like good behaviour. The audio should be simply bit-shifted to occupy the 2nd to 17th most significant bits of a 24-bit depth (effectively the way an HDCD-compatible CD player would play back a normal CD) so there's no loss of information.

Interestingly using lossyFLAC, the peak was 0.515625, implying that as lossyWAV doesn't suffer from clipping on positive full scale samples, it can better round those samples (zeroing 10-bits out of the original 16) and zero as many bits as it calculates it should. It resulted in slightly lower bitrate for lossyFLAC -standard.

Despte the feeling that this isn't what I'd expect, this is actually a workable state of affairs for me, as I use ReplayGain and lossyWAV and FLAC and thus don't care about a lossless bit-shift and 6.02 dB attenuation of normal CDs because the original loudness is nothing sacred to me - in fact I often bake Album Gain into my lossy encodes by passing Album Gain-adjusted audio to the encoder in foobar2000 at 24 or 32 bit depth. I still get correct AccurateRip and CTDB logs from CUEripper regardless of whether I keep a 16-bit or 24-bit lossless, or some kind of lossy file, but I can't re-verify anything other than 16-bit lossless in CUETools.

So in summary, fully-automatic HDCD detection in CUEripper only works if I'm happy to bit-shift all my redbook CDs one-bit to the right (6.02 dB quieter) and store them in 24-bits. Fine with FLAC or lossy codecs. Not great if I need ALAC, but I'm not tied to any Apple products (aside from the iPad of the group I edit ALAC backing tracks for, which I do under a separate Windows User account, so if ripping CDs I'd be OK ripping to 16-bit on that account), and get a minor advantage when using lossyWAV.

If I want to stick to normal 16-bit rips for normal CDs, I'll have to accept that I'll only get HDCD decoded if I use full lossless when ripping (and use fb2k's HDCD decoder or Windows Media Player's) or if I notice the HDCD logo and either change my settings (DetectHDCD=1) for that rip alone or post-process in CUETools. Fortunately HDCD was fairly short-lived around the late 1990s (I think the only HDCDs I have are this Alabama CD and a bunch of Dire Straits Digital Remasters in storage) and they seem to sound good without decoding thanks to very modest soft limiting compared to today's Loudness War standards.

Either option is OK for me. I'll probably stick to the latter - 16-bits unless I notice the HDCD logo, but could happily change my mind with no change to my workflow.

I think dBpowerAmp might do what I hope, but when I trialled it, I didn't have an HDCD to hand to test it. I need to reinstall Windows soon, so perhaps I'll trial it again and consider buying it again. It's important that if only three tracks of 22 have HDCD features, the whole disc is still played back at -6.02 dB gain. Then again, most of my ripping is complete, aside from a few old rips I made when hard disks were much smaller and I couldn't afford to use lossless.

As I've mentioned before I'd quite like a ripper that will detect and decode HDCD discs if I come across them, and ideally detect and correct those rare early PRE-emphasised CDs with non-flat EQ, which I don't think I've ever played. (I don't know whether CUETools can deal with PRE-emphasis, but hope it may be noted in CUEsheets if nothing else).

Porcus, I had no idea until yesterday that pre-emphasized discs could fail to have a TOC flag, so thanks for the info.

Does anyone know if CueRipper looks in both the TOC and subchannel for pre-emphasis detection? If so, are special settings required or does it do it by default? I ripped my version of DSOTM with CueRipper and pre-emphasis was not noted in the cue or log files, but I can't tell if pre-emphasis was checked but not detected or wasn't checked.

I just tested with CUERipper 2.1.4 and my DSOTM, which has pre-emphasis flags in the subcode only, not in the TOC. I get FLAGS PRE in the cue sheet. So yes, CUERipper looks in the subcode.

Unrelated observation:

The new cover art feature of CUERipper is neat. However, I had a disc for which there were apparently multiple matches. CUERipper got the right metadata, but the wrong image was showing. I clicked on the image, and it changed to another wrong image. I clicked again, and it just kept toggling back and forth between them. On Discogs, the release doesn't have an image uploaded yet. I couldn't figure out how to get CUERipper to select "no image", though...it insisted I pick one of the available bad ones. Did I miss someting? I ended up disabling the cover art search in the options.

Also:

In CUERipper's EAC-style logs, I assume the track quality should be less than 100.0 if re-reads were required, and "Copy finished" should be the last message if the re-reads weren't able to produce a match. Yet, it seems to be "Track quality 100.0%" and "Copy OK" even when these conditions aren't met.

Some drives may require commands other than the current MMC standard (or additional commands required).This can't be just switched on in the program. The program developer may or may not add features for drives that are no longer manufactured to a future release.

The leading 0 is not being added (not removed). The UPC code is 12 digits. The EAN code includes an extra digit at the beginning. The (CUE file) CATALOG tag requirement is the 13 digit EAN code. CUETools and CUERipper should be padding a zero to the beginning when retrieved codes are 12 digit UPC. I believe this has been reported but thanks for bringing it up again.