item wrote:

It's a very novel sensation for me to be arguing that 'bits are bits'! But its very simple to prove categorically that the binary data on the disc is identical to the ripped version. More importantly, where there are errors, they are punctiliar and rare. In other words, it's hard to imagine how they could combine systemically to change the 'character' of the file. This idea is exactly like saying 'my digital photograph changes colour when I move it to a different partition'. In a very unusual scenario, you might lose a pixel, or corrupt a file header, but it will never turn sepia! The behaviour of the optical drive will make a characteristic difference to the 'colour' of the playback. We can look to the hardware - and even software - but we can't blame the data.

item wrote:

Let's just be grateful things have moved on from those nasty plastic discs . . . in an ideal world I like to call the future, we would download our files from the mixing desk direct to our highly optimised audio computers/streamers/digital transports and music would never get tangled up in optical media, with all its resource-hungry correction and crude mechanical apparatus. In the meantime, MD5 checksums (for instance) give us complete confidence that a copied file is 100% accurately transferred from disc. Playing that file as well as the disc-spinner is the benchmark computers have aspired to, but in many cases have now surpassed.

item wrote:

In similar vein to our machines, Romy (which you're not likely to hear over there), have you tried the Auraliti players? They're capable of pretty nifty performance.

Romy the Cat wrote:

oxric wrote: By analogy, an Item Audio equipped with an optional blu-ray drive would serve precisely this function. It would spin a disc, extract the data and code it so that it is available for the next stage in the chain. Yes it might but it needs to do it in real time. I do not think at this point Item Audio “transport” performs this rudimental transport duty.  oxric wrote: Reviewer bashing Romy? Without knowing who it is and what was said? Why do I need to know who and under which circumstance said anything? Any persons who practice audio not for own benefits but for interests of “others” as far as I’m concern might go fuck himself. I understand that you do not “get” it yet but you do see me insisting that you obliged to get anything, do you. Please do not response to it. The Cat

item wrote:

On a really fundamental level, this conversation isn't working.

Romy the Cat wrote:

It was exactly what I was experimenting for many times since 2005 and I came to exactly opposite finding. I am not able to make neither LP, tape or CD to copy in digital that would sound like original source. I am able to do it with FM – I can record it and to play undistinguishable but no other souses that I have. But what do I know – I do not run the Hi-Fi review but from another hands I so not sell to anybody my concussions... You do.

Romy the Cat wrote:

Oxric, I have no idea what your “literature” was all about. If the Item’s company does not name thier read-only DAWs as “transport” it would be no conversation at all. For sure the analog PS for PS that they do is very interesting thing and very much unknown thing but they have no guts of apparent expertise to make any claims about sonic benefits of it. They use a feedback of some kind of idiot-reviewer and some kind of reference. Pay attention that the feedback was not about sound of DAW but how it compares to some kind of CD transport – how much more idiotic it could be, particularly know that this machine is NOT a transport. Anyhow, I do not make any claims about their DAWs and perhaps Item is not a technical or sonic brain of the company. It might be a good machine and you need to buy it right, after renew your subscription to Hi-Fi Review.

item wrote:

For future reference, in case anyone else is as confused as I am about the content of this thread; from the horse's mouth: the Item DAT1 could just about be considered a 'DAW' (the SPDIF version records analog, and you can run editing and mixing suites on it). However, it is a CD converter (it rips CDs to AIFF, WAV, FLAC, etc files). It is a CD player. Above all - it is a universal digital file player and streamer with onboard storage.

Any computer does absolute the same level of universality by being a digital file player. My telephone does it but I do not call my telephone a “digital transport”.  Ripping CD it is not what your devise does but the free software that you use. So, any other PC would do it.

item wrote:

I have no further comment to make about such controversial or subjective matters, and I don't want to be seen to be promoting our machine: only to set the record straight about what it is and does.

No one prohibit you to make promotional statements but you need to live with consequences if your statements are not accurate or do not make any sense. In your commentary that content of audio CD is identical to a wav file and could be bit-for bit compared you went to pure world of fantasy.

item wrote:

It remains highly controversial whether the effect of on-the-fly decompression of lossless formats such as ALAC and FLAC create audible artefacts

Why is it controversial is in case of  FLACing the bit-for bit comparing before and after is perfectly possible?

item wrote:

Having said that, there is some wriggle room for two identical rips to perform differently because of their different positions on the drive and possible fragmentation, resulting in a different pattern of interrupts and EM noise created by different patterns of drive read access. But again, many find this stretches the limits of plausibility.

Why you suddenly give a room to possibility of any wriggling if you insist that bit-for-bit comparing between audio CD and bit stream file is possible? If you have two digital cables with very different sound then are you sure that they will not pass your bit-for-bit test? What, do you think that one of the cables is just losing bits somewhere during transition?

item wrote:

The problem is that you can never made a level playing field comparison between a CD and its ripped clone, because the hardware is so instrumental in the performance of the transport.

item wrote:

If you built a machine purely as a CD converter, it would be interesting to experiment with different power supplies to determine whether a higher number of errors get through the sieve when rail noise is higher. It has been well documented that different CD-ROM mechs create higher or lower read errors, and obviously these are not desirable, but from the playback viewpoint, once the file is encoded, the processor takes the file as read: it's not error checking against the CD.

item wrote:

Again, we're missing even the flimsiest theoretical framework for a mechanism by which one in a million bit errors during ripping can translate to any characteristic difference in the resultant file. Especially when we consider that during playback those micro rip 'errors' are not errors at all: they look like valid data.

Romy the Cat wrote:

Any computer does absolute the same level of universality by being a digital file player. My telephone does it but I do not call my telephone a “digital transport”.  Ripping CD it is not what your devise does but the free software that you use. So, any other PC would do it. Yes, the hardware is very instrumental in the performance of the transport and you in your devise have no specialty hardware to be a transport. You stick in your PS $15 CD room drive and make EAC to rip the data from the disk. Absolutely any computer, including my TV, phone and perhaps a refrigerator can do it but I do not call them digital transports. Why suddenly “errors” became a new bid wolf. You need to read more or to ask somebody to explain it to you. The errors them are not a big deal and the errors are not the cause of the change in the sound that we hear with different transports. Again, talk to your magazine editor. They are very basic things and he shall be able to explain it to you. Writing those pretentious marketing proclamations you need at least to be informed what you saying.

1) I play a CD on an 'excellent' CD transport. I take the digital output from this (spdif or AES) and connect it to a PC interface (a Lynx or RME card). I capture the digital output on the PC as a .wav file using Wavelab or something similar.

2) I rip the CD to a .wav file using EAC or DBPoweramp.

3) I play both files back using the same PC and software player.

Would the two files sound different? If so, why? (Unfortunately, I don't have an 'excellent' CD transport to hand, otherwise I would try this.)

Mani.

Romy the Cat wrote:

fiogf49gjkf0dItem, you are not getting the point that ripping implied the initial read of CD by CD-ROM drive and their possess looks like kills the quality of the file you made on your “super PC”. If you imply that your PC plays a file that was not made from the same CD then you compare apples and oranges. Making claims that “well-designed PC transport is better than a good CD transport” is a ridicules claim if your CD-ROM and your CD transport use different source. Again take the same CD, play it at your CD passport. Then rip the same CD to your super-duper PC and play it into the dame DAC. If you find that your PC outperform you CD transport then… trash your CD transport and get the one that sound better, not the one that your magazine editor told your that that it “sounds good”. Rgs, Romy the Cat

Sector Transfer rate

=
=

176400/2352 sectors/second
75 sectors/second

1 MByte AUDIO    

=
=
=

1048576 bytes
1048576/2352 sectors
446 sectors

333000 sectors 

=
=
=
=

333000/75 seconds
4440 seconds
4440/60 minutes
74 minutes

333000 sectors 

=
=

333000/446 Mbytes AUDIO
747 Mbytes AUDIO

This method can not be used for a Data-Bytes as the data would be corrupt. To fix this problem a DATA sector contains both Data and CRC-CCITT Information.

CRC-CCITT is a 16 bit EDC (Error Detecting Code). For every byte of data a 16 bit CRC code is calculated, resulting in 128 CRCs, 16 bits each. These CRCs, therefore, take up 256 bytes of the 2352 bytes available. The remaining 48 bytes are reserved for future use. This leaves 2048 bytes available for actual Data.

It seems 65min of 74min is audio data (2048 bytes of 2352) . the only thing could convince me the ripped audio data is not equal to optical disk is that cd rom could not read correct data and cdplayer could do that.