IPB

Welcome Guest ( Log In | Register )

102 Pages V  « < 78 79 80 81 82 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
korth
post Sep 8 2012, 17:37
Post #1976





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



QUOTE (korth @ Sep 8 2012, 12:56) *
%filename%[ - %unique].accurip
Ooops, that should've been %filename%[ - %unique%].accurip.

This post has been edited by korth: Sep 8 2012, 17:39


--------------------
korth
Go to the top of the page
+Quote Post
Manlord
post Sep 9 2012, 21:36
Post #1977





Group: Members
Posts: 25
Joined: 2-April 10
Member No.: 79529



Has anyone tested CUERipper under Mono?

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: b03f5f7f11d50a3a
The 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


This post has been edited by Manlord: Sep 9 2012, 21:37
Go to the top of the page
+Quote Post
Corwin
post Sep 11 2012, 05:39
Post #1978





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



QUOTE (korth @ Sep 8 2012, 08:37) *
Ooops, that should've been %filename%[ - %unique%].accurip.


Thank you for agreeing with me that this should have worked:

Go to the top of the page
+Quote Post
korth
post Sep 11 2012, 13:13
Post #1979





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



I did not agree with you. You didn't follow the quote-link back to my original message on the previous page. That file is not named by the template.

This post has been edited by korth: Sep 11 2012, 13:19


--------------------
korth
Go to the top of the page
+Quote Post
Corwin
post Sep 12 2012, 05:26
Post #1980





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



QUOTE (korth @ Sep 11 2012, 04:13) *
That file is not named by the template.


Ahh, I understand. It's working correctly now. Thank you very much for your time in understanding this.
Go to the top of the page
+Quote Post
wipeout
post Sep 12 2012, 22:42
Post #1981





Group: Members
Posts: 5
Joined: 28-March 04
Member No.: 13053



QUOTE (korth @ Sep 4 2012, 04:32) *
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?

Thanks again for an awesome suite of tools.
Go to the top of the page
+Quote Post
Corwin
post Sep 20 2012, 00:53
Post #1982





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



When I do a Verify [default], all is good. AR 2 (Offset 676), CTDB 1:



When I do a Encode [fix offset], I get AR: disk not present in database.
Go to the top of the page
+Quote Post
korth
post Sep 20 2012, 04:09
Post #1983





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



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.

This post has been edited by korth: Sep 20 2012, 04:26


--------------------
korth
Go to the top of the page
+Quote Post
Miguk
post Sep 22 2012, 14:54
Post #1984





Group: Members
Posts: 32
Joined: 24-November 08
Member No.: 63054



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.

This post has been edited by Miguk: Sep 22 2012, 15:02
Go to the top of the page
+Quote Post
korth
post Sep 22 2012, 15:20
Post #1985





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



Corwin, I might be away for a while so let me give you one scenario where the AccurateRip ID could change resulting in "not found".
  • Say the folder contains a flac image, cue and rip log, each similarly named.
  • The cue does not have the REM DISCID tag or it's value is 6108EA08.
  • 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).
Two different AccurateRip ID's, two different results.


--------------------
korth
Go to the top of the page
+Quote Post
lvqcl
post Sep 29 2012, 13:48
Post #1986





Group: Developer
Posts: 3371
Joined: 2-December 07
Member No.: 49183



http://www.cuetools.net doesn't work, and CUETools cannot connect to its database sad.gif
Go to the top of the page
+Quote Post
eas
post Sep 29 2012, 19:55
Post #1987





Group: Members
Posts: 4
Joined: 3-October 05
Member No.: 24867



QUOTE (lvqcl @ Sep 29 2012, 04:48) *
http://www.cuetools.net doesn't work, and CUETools cannot connect to its database sad.gif


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.

I guess we can cross our fingers and wait.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Sep 29 2012, 23:03
Post #1988





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



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

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

This post has been edited by Gregory S. Chudov: Sep 30 2012, 03:50


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Dynamic
post Oct 2 2012, 21:09
Post #1989





Group: Members
Posts: 810
Joined: 17-September 06
Member No.: 35307



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.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=0
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1
Which 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: 1
No 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: 2
No 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: 3
No 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: 4
No 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: 5
No 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: 6
No 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: 7
No 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: 8
No 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: 9
No 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: 10
No 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: 11
No 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: 12
No 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: 13
No 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: 14
No 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: 15
No 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: 16
No 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: 17
No 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: 18
No 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: 19
No 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: 20
No 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: 21
No 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: 22
No 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:
CODE
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=1
CreateM3U=0
CreateCUEFileWhenEmbedded=1
Truncate4608ExtraSamples=1
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=0


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.
CODE
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=1
CreateM3U=0
CreateCUEFileWhenEmbedded=1
Truncate4608ExtraSamples=1
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1


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.

(edit: put linebreaks in CODEBOX to prevent excessive width of post)

This post has been edited by Dynamic: Oct 2 2012, 21:14
Go to the top of the page
+Quote Post
Porcus
post Oct 3 2012, 00:08
Post #1990





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (Dynamic @ Oct 2 2012, 22:09) *
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).


* HDCD: Can be detected and decoded afterwards, as long as you stick to lossless. Therefore I do not convert -- I decode on-the-fly with http://www.foobar2000.org/components/view/foo_hdcd .

* Pre-emphasis: CUETools does (since when I don't know) detect and write to .cue -- although, a reservation: I don't know (and didn't bother to search) whether CUETools checks both TOC and subchannel to find those which aren't flagged in both (notably, one Dark Side Of The Moon was reported released with this defect -- and one Abbey Road). Unlike HDCD, you need to know this when you rip. Again, it can be decoded on-the-fly with http://www.foobar2000.org/components/view/foo_dsp_effect , provided tagged. (Myself I do also keep my pre-emph'ed CDs in a different format ... making me, for the sake of 54 CDs, a WavPack user.)
There are quite a few CDs that at some stage were released in a pre-emph'ed master. A few reported here: http://www.studio-nibble.com/cd/index.php?..._(release_list) .

This post has been edited by Porcus: Oct 3 2012, 00:14


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Dynamic
post Oct 3 2012, 19:07
Post #1991





Group: Members
Posts: 810
Joined: 17-September 06
Member No.: 35307



Thanks, Porcus, that's useful info.
Go to the top of the page
+Quote Post
godrick
post Oct 4 2012, 15:44
Post #1992





Group: Members
Posts: 306
Joined: 31-December 10
Member No.: 86948



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.
Go to the top of the page
+Quote Post
mjb2006
post Oct 7 2012, 07:15
Post #1993





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



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.

This post has been edited by mjb2006: Oct 7 2012, 07:36
Go to the top of the page
+Quote Post
DT5
post Oct 9 2012, 19:53
Post #1994





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



When I compare EAC with CUETools then I am missing the ISRC in the cue-files.
Do I have to switch this feature on or cannot CUETools handle it (yet)?

When I use CUERipper and i get the option to choose a cover art. Is it possible to see the width and height of it (before I start ripping)?
Can I use my own scans?

CUETools has the option to submit results to CTDB.
I cannot find it for CUERipper. Does it always submit?
Go to the top of the page
+Quote Post
korth
post Oct 10 2012, 00:19
Post #1995





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



CUERipper can read the ISRC codes from the CD on some drives. If you know your drive can read them, you might want to provide the make and model.

I too would like to see the cover art size displayed in CUERipper. The cover art is retrieved from MusicBrainz & Discogs. You currently can't select your own.

CUERipper always submits rip results.


--------------------
korth
Go to the top of the page
+Quote Post
korth
post Oct 10 2012, 01:26
Post #1996





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



Waited too long to edit previous post.
CUERipper always submits {new} rip results. It won't submit the same result more than once.


--------------------
korth
Go to the top of the page
+Quote Post
DT5
post Oct 10 2012, 06:35
Post #1997





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



QUOTE (korth @ Oct 10 2012, 00:19) *
CUERipper can read the ISRC codes from the CD on some drives. If you know your drive can read them, you might want to provide the make and model.


I used a Plextor PX-716A to test it and it can read ISRC (by using EAC).
So I have manually no chance to switch it on and have to wait for a new release to support it?
Go to the top of the page
+Quote Post
DT5
post Oct 10 2012, 14:22
Post #1998





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



Also my LG GSA-5163D supports ISRC.
Are there really drives who do not support that feature?

CUETools and certainly also CUERipper seem to be buggy when they write the CATALOG #:
CUETools: CATALOG 731454256223
EAC: CATALOG 0731454256223

CUETools is removing the leading 0. But it has to be a 13 digit number.


This post has been edited by DT5: Oct 10 2012, 14:25
Go to the top of the page
+Quote Post
Manlord
post Oct 10 2012, 15:00
Post #1999





Group: Members
Posts: 25
Joined: 2-April 10
Member No.: 79529



QUOTE (DT5 @ Oct 10 2012, 15:22) *
CUETools and certainly also CUERipper seem to be buggy when they write the CATALOG #:
CUETools: CATALOG 731454256223
EAC: CATALOG 0731454256223

CUETools is removing the leading 0. But it has to be a 13 digit number.


Are you referring to the barcode? The format of the catalog number is label dependant. Some labels use more digits and some less.

There are barcodes with 12 and 13 digits. 12 digits are UPC codes and 13 digits are EAN codes:
http://www.gs1us.org/resources/standards/ean-upc
http://www.adams1.com/upccode.html
http://en.wikipedia.org/wiki/Universal_Product_Code
http://en.wikipedia.org/wiki/International...umber_%28EAN%29

Go to the top of the page
+Quote Post
korth
post Oct 10 2012, 15:23
Post #2000





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



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.

This post has been edited by korth: Oct 10 2012, 15:25


--------------------
korth
Go to the top of the page
+Quote Post

102 Pages V  « < 78 79 80 81 82 > » 
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: 2nd September 2014 - 08:49