Talk:Extended Resolution Compact Disc

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Untitled[edit]

Em, anon user 194.89.XXX claims to remove garbage but instead add plenty of garbage of his/her own. Owing to the difficulty in understanding some of his/her phrasing ("the purest form of SACD") as well as the obvious factual disparities ("analogue"; "unlike HDCD, XRCD refers purely to the optimal quantization of the source materials" - which is precisely what HDCD does), I have restored much of the article. My advice is if you want to change something, please check out the accuracy via some form of online research. Pls don't introduce vulgarities in the edit summary, especially when one's contributions are considerably worse off than previous editors'. Mandel 08:04, 12 October 2005 (UTC)[reply]

My first edits were somewhat hasty, which I admit, but now I think that the article is extremely well-off. Before my edits, it not only had what I perceive as layman's *opinions* but also a multitude of factual errors. If something is run through a digital-to-analogue converter, the resulting material definitely isn't going to be digital. This claim was what lead me to believe that there is only a slightly poor phrasing there, so I thought I'd correct it quickly. After a while, however, I noticed that there was a LOT to be corrected with the article. Regarding your "precisely what HDCD does" bit, that's not true at all - there is a lot of matters at work with HDCDs. The stream has extra control information studded in the least significant bits and a HDCD decoder will react to it, providing improved dynamics or whatever the mastering engineer has deemed a passage to need. An XRCD on the other hand DOES NOT have any special control information or the like. It will be EXACTLY a regular CD, albeit done as well as possible. Of course, a HDCD will also be according to redbook standard, but its least significant bits will be used for the control data instead of audio quality. I'm trying to understand why you keep reverting when I'm clearly trying to improve the article. Let's work this through. 194.89.2.126 11:12, 15 October 2005 (UTC)[reply]

"Still, XRCDs are optimally the very best the Compact Disc can offer" ... Isn't this a bit of a tautology? Optimally, any CD is the best CD can be. That's what optimal means. --68.41.122.213 11:26, 15 December 2005 (UTC)[reply]

Fair use rationale for Image:XRCD.jpg[edit]

Image:XRCD.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 11:14, 6 July 2007 (UTC)[reply]

It is not format[edit]

XRCD is not an technical format; it is a recording process. i think that this articel must be removed or moved to another section. —Preceding unsigned comment added by 89.163.43.108 (talk) 11:59, 8 March 2008 (UTC)[reply]

Agree 100% and came here to say the same. This shouldn't be listed as a format. 2.25.126.224 (talk) 20:49, 15 February 2012 (UTC)[reply]

Audiophile talk[edit]

Somebody please note that this article is written from an audiophile's point of view. Somebody should say that this JVC process itself is much more expensive than necessary. The fact that you paid $10,000,000,000 for audio hardware by itself does not mean that the output is better than from a $1000 worth equipment.

The medium where the digitized data is stored (magneto-optical) has no influence to sound quality. Any flash thumb drive could be used. The extremely precise production of the final medium (compact disc) is overkill if a regular compact disc can yeald perfect copy. If this were not the case, no computer programs could be run from CDs. There is no reason why a DAC should synchronize its clock to the data medium. Just get a low jitter clock and play any source at "Rubidium quality".

I am not very knowledgeable about audio jitter, but something tells me that once the ADC has produced jittery result no digital processing can reduce it. What do experts have to say about this matter? -- J7N —Preceding unsigned comment added by 83.99.184.75 (talk) 13:26, 15 March 2008 (UTC)[reply]

I agree that it's quite unlikely this actually did anything useful. That said, there's a big difference between CD-ROM and Compact Disc Digital Audio. CD-ROMs (well mode 1 which is what you're likely to find for normal data storage), use far more of the CD for error detection and correction and a header, only 2048 bytes per sector is actual data. CD-DA uses 2352 bytes. There's also a big difference between how they tend to be handled. If an error is detected on a CD-ROM and it can't be corrected with the ECC, it will normally be re-read until it's okay or the drive will report an error. Most CD players just read the drive at 1x speed. If there's an error, a fancier player will interpolate, a dumber player will just play it anyway. The much lower level of ECC and the greater difficulty seeking means even if you want to, it's actually far less effective to try again. Even with CD-ROM drives, their actual support for trying to properly read the data using what was on the CD was often limited, hence why tools like Exact Audio Copy arose. That said, the error rate tends to be fairly low, and errors are most likely to arise because of damaged (scratched etc) or dirty CDs, it's quite unlikely better glass masters will make any difference. But still anyone who was trying to read CDs especially in the late 1990s with a CD-ROM drive would know from comparing reads with tools like EAC, that it can easily be far from bit perfect each time. BTW, as for jitter, again I have strong doubts that the techniques actually did anything useful, but as I understand it, there are two forms of jitter which may be referred to and I didn't bother to read to understand what they're trying to say. One issue is sampling jitter, relating to the mastering of the audio (well or playback which you have no control over) Jitter#Sampling jitter [1], the other is read jitter Jitter#Compact disc seek jitter [2], relating to what I said earlier namely CDs lack the header information so you can't easily seek to an exact sector. There is a lot of misinformation and misleading claims about the evils of jitter, including the belief that playback jitter can be influenced by the accuracy of the CD master which AFAIK is almost definitely not correct, and in fact a lot of people talking about this don't even understand jitter or digital audio or CD-DA. ([3] has a somewhat okay overview, the author isn't an expert on digital audio but I think they do have reasonable knowledge and they do mention it's mostly theory. Then see [4] which seem to explain why even in theory it's unlikely, maybe also [5] and [6] and [7].) But I believe it is possible that jitter during mastering of the audio (I mean the ADC etc for getting the audio into digital, not the glass master) especially from 1980s equipment could cause issues. See e.g. [8]. (Because of the misinfo, I've restricted my links to places where such nonsense isn't tolerated.) Likewise some seem to think that seek jitter could be affected by the quality of the master, but I'm pretty sure that it's not very likely and more importantly it's only likely to matter when you need to seek to re-read something. I mean maybe really really crap CD players from the 1980s would have problems if they had absolutely no buffer so taking slightly too long to read a sector could cause issues, but I think that was very rare or non existant Nil Einne (talk) 18:26, 18 January 2019 (UTC)[reply]

Snake oil[edit]

Most of "information" in this article is pure marketing bullshit which doesn't make any sense. —Preceding unsigned comment added by 80.235.91.45 (talk) 14:02, 15 June 2008 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Extended Resolution Compact Disc. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:36, 26 September 2017 (UTC)[reply]