unitserve rips vs core rips

http://soundcrafthifi.com/media/catalog/product/cache/1/thumbnail/9df78eab33525d08d6e5fb8d27136e95/c/o/core_power_supply.jpg and Naim's own webpage suggests that the CD drive in the Core is a TEAC CD-SN250. Unfortunately, this drive is not listed in http://www.accuraterip.com/driveoffsets.htm. Best, nbpf

(Edit: as already discovered by SJBABBEY)

In simple layman's language, what exactly is the significance of "drive offset" ?

The figures quoted in the accuraterip database seem to range from +6 to well over 1,000.

From the Hydrogenaudio wikisite:

Quote

Very few CD drives actually start reading data from audio CDs exactly at the sector requested by DAE (Digital Audio Extraction) software. There are drives that are off by over 1 sector (1/75th of a second), but most are off by much less (¹/₂₅₀ to ¹/₃₅₀ second). Most modern CD drives have "Accurate Stream" technology, so there's no "jitter", meaning in this case that the variance is consistent from read to read, and will tend to be the same for all drives of a certain make & model.

The AccurateRip database allows one to find out the read offset, which is normally constant for given make & model of CD drive. This number can then be used by DAE software to ensure that each track is ripped from its exact start to its exact finish.

The offset is given in samples. One "sample" on an audio CD is 4 bytes, consisting of a 2-byte left-channel value and a 2-byte right-channel value. There are 2352 bytes, or 588 samples, in each sector of an audio CD, corresponding to 1/75th of a second of sound. Therefore, an AccurateRip offset of +134 means the drive consistently delivers data from 536 bytes behind (earlier than) where it was asked to read from, so the DAE software needs to look that far ahead (hence the positive offset) in order to get the right data.

unquote

sj, thank you for that information.

This is why I asked Simon earlier if his data stream 0000abcdefghijklmnop000000000000000 represented a complete (5 minutes) of music, or just a very small sample and, equally importantly, whether the actual number and distribution of 0000's before and after the musical data was significant. I am now working on the basis that this is a very very small "sample" of the music, which has to be delivered at a very, very precise time. The 0000's control the very, very precise time ?

Presumably, if the data a-p is different, the RIP is not perfect. ?

Also, If the number of 0000's before or after the music data varies in between each sample, eg sometimes it's 19x0000's and other times it's 5x0000's and all variations in between, then something like "jitter" is occuring. ?

If the total number of 0000's between the music data remains constant at 19x0000's, but the distribution before and after changes eg 4x0000's before and 15x0000's after become 6x0000's before and 13x0000's after, what effect does this have on the music. ?

Sorry to be a pain over this, but some of us (ok, probably just me!!) like to be a bit more precise in our understanding of these technical things, regardless of what the sound quality is like !

Don Atkinson posted:

This is why I asked Simon earlier if his data stream 0000abcdefghijklmnop000000000000000 represented a complete (5 minutes) of music, or just a very small sample and, equally importantly, whether the actual number and distribution of 0000's before and after the musical data was significant. I am now working on the basis that this is a very very small "sample" of the music, which has to be delivered at a very, very precise time. The 0000's control the very, very precise time ?

 

I think Simon is just giving a simplified version (0000abcdefghijklmnop000000000000000) because if he showed the full track of music, 42430128 bites of data would make a very long and tedious read, and might even be in breach of copyright.

ChrisSU posted:

Don Atkinson posted:

This is why I asked Simon earlier if his data stream 0000abcdefghijklmnop000000000000000 represented a complete (5 minutes) of music, or just a very small sample and, equally importantly, whether the actual number and distribution of 0000's before and after the musical data was significant. I am now working on the basis that this is a very very small "sample" of the music, which has to be delivered at a very, very precise time. The 0000's control the very, very precise time ?

 

I think Simon is just giving a simplified version (0000abcdefghijklmnop000000000000000) because if he showed the full track of music, 42430128 bites of data would make a very long and tedious read, and might even be in breach of copyright.

This is my understanding as well. It is probably useful to distinguis between intuitive, informal notions of "bit perfectness" and "equality" and more technical, operational notions. A tipical log from rubyripper, for instance, looks like the following:

--- start log:

This log is created by Rubyripper, version 0.6.2
Website: http://code.google.com/p/rubyripper

Cdrom player used to rip:
Lenovo Slim_USB_Burner 8L32
Cdrom offset used: 6

Ripper used: cdparanoia
Matches required for all chunks: 2
Matches required for erroneous chunks: 2

Codec(s) used:
-flac -> --compression-level-5 -V (flac 1.2.1)

CDDB INFO

Artist = Quadriga Consort
Album = On a Cold Winter's Day
Year = 2012
Genre = Unknown
Tracks = 18 (18 selected)

01 - A Wassail, a Wassail English traditional
02 - 'Twas in the Moon of Wintertime Huron traditional
03 - The Moon Shines Bright English traditional
04 - Tune No 176 Turlough O'Carolan (1670–1738), Ireland
05 - The Holly and the Ivy English/French traditional
06 - A Naoidhe Naoimh Scottish traditional
07 - To Shorten Winter's Sadness Thomas Weelkes (1576–1623)
08 - Don Oíche Úd I mBeithil Irish traditional
09 - Christmas Eve – Christmas in Killarney – Christmas Day in the Morning – The Day before Christmas Irish traditionals
10 - Pat-a-Pan English/French traditional
11 - Tàladh ar Slànaighear Scottish Gaelic traditional
12 - On a Cold Winter's Day Irish traditional
13 - A Babe is Born All of a Maid English traditional
14 - This is the Truth Sent from Above N.Newerkla
15 - Wexford Carol English/Irish traditional
16 - Gower Wassail Welsh/English traditional
17 - Drive the Cold Winter Away English traditional
18 - Deck the Hall English traditional

STATUS

Starting to rip track 1, trial #1 (43 seconds)
Starting to rip track 1, trial #2 (41 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 896ee98d34efe207d786402e0b65bc7d

Starting to rip track 2, trial #1 (46 seconds)
Starting to rip track 2, trial #2 (46 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 760dff5a934266ad8e30a8a65b391aad

Starting to rip track 3, trial #1 (43 seconds)
Starting to rip track 3, trial #2 (43 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: cb9e289bda2bb0191aefcf189d65998c

Starting to rip track 4, trial #1 (19 seconds)
Starting to rip track 4, trial #2 (19 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 907835dbbaf6dde75d98d644e9512b1d

Starting to rip track 5, trial #1 (48 seconds)
Starting to rip track 5, trial #2 (48 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: a0da59c79b8c24f64a2a78d2285ef5c5

Starting to rip track 6, trial #1 (31 seconds)
Starting to rip track 6, trial #2 (31 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: e6c28b59bc958d5f8641b856d793ffcb

Starting to rip track 7, trial #1 (36 seconds)
Starting to rip track 7, trial #2 (36 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 60fa9cd19f405f26d163108195753439

Starting to rip track 8, trial #1 (39 seconds)
Starting to rip track 8, trial #2 (39 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 1b757c40654594c2390d11998f97d4bd

Starting to rip track 9, trial #1 (37 seconds)
Starting to rip track 9, trial #2 (34 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 56026eef6d36525bd5586bd82b4179c1

Starting to rip track 10, trial #1 (20 seconds)
Starting to rip track 10, trial #2 (20 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: d65f95c74f699bc6bfe6f5c6b1f6b325

Starting to rip track 11, trial #1 (33 seconds)
Starting to rip track 11, trial #2 (33 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: c27b09add878bcfa9aaafeac0d0bffd5

Starting to rip track 12, trial #1 (22 seconds)
Starting to rip track 12, trial #2 (22 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 01f8b152e9bde18cdf76638e06ca62b1

Starting to rip track 13, trial #1 (41 seconds)
Starting to rip track 13, trial #2 (41 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 29d4dce06a8017491412a13d4c26d093

Starting to rip track 14, trial #1 (33 seconds)
Starting to rip track 14, trial #2 (33 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: e0b81af6a2a697dd72683fa4b2246ad5

Starting to rip track 15, trial #1 (50 seconds)
Starting to rip track 15, trial #2 (50 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: a3b1662a7795dd939bba63fd36645eb4

Starting to rip track 16, trial #1 (28 seconds)
Starting to rip track 16, trial #2 (28 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: ce3432aeafaaff68743319b386d3b04d

Starting to rip track 17, trial #1 (22 seconds)
Starting to rip track 17, trial #2 (22 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 1cf7b10cc0245e3ab7fd4e5226e4dd7b

Starting to rip track 18, trial #1 (18 seconds)
Starting to rip track 18, trial #2 (18 seconds)
Analyzing files for mismatching chunks (0 second(s))
Every chunk matched 2 times
MD5 sum: 5a0ca7447b782a679482a78e5c3bbade

RIPPING SUMMARY

All chunks were tried to match at least 2 times.
None of the tracks gave any problems

--- end log

From the example, we see that the drive offset used was 6 (manually set by me), that all chunks were required to match 2 times and that all chuncks did indeed match 2 times. Rubyripper would report failures to satisfy the required number of matchings and eventually abort. I do not remember whether in the specific case the requirement of 2 matches was a default value or whether I did specifically set this value.

But this does not really matter. What matters is that a number of conditions have to be met for a rip to be considered successful (or, for that, for two files to be considered equal) and that notions of bit perfectness (equality) can only be defined operationally in terms of such conditions.

Thus, for instance, two files on NAS devices are usually considered to be equal if their (e.g., MD5) checksums coincide. In practice, this means that the probability that the two files are equal is very high but not that they are certainly equal. On the other hand, stronger notions of equality can be applied to files stored on the same device.  

ChrisSU posted:

Don Atkinson posted:

This is why I asked Simon earlier if his data stream 0000abcdefghijklmnop000000000000000 represented a complete (5 minutes) of music, or just a very small sample and, equally importantly, whether the actual number and distribution of 0000's before and after the musical data was significant. I am now working on the basis that this is a very very small "sample" of the music, which has to be delivered at a very, very precise time. The 0000's control the very, very precise time ?

 

I think Simon is just giving a simplified version (0000abcdefghijklmnop000000000000000) because if he showed the full track of music, 42430128 bites of data would make a very long and tedious read, and might even be in breach of copyright.

Hi Chris (and others)

I wasn't criticising Simon on his example. In fact I found it a very useful example. And I certainly didn't expect Simon, or anybody else, to show the full detailed track of music, all 42,430,128 bites of it !!!!

But i'm still not exactly clear what those 0000's at the start and end of Simon's example actually represent. And more importantly, how they might affect the sound quality if the ripper doesn't copy them accurately.

Just to let you know that I've advised Phil Harris of the offset difference that Simon identified and of the differences that some of us can hear between the two rips. 

Stay tuned...

Don Atkinson posted:

ChrisSU posted:

Don Atkinson posted:

This is why I asked Simon earlier if his data stream 0000abcdefghijklmnop000000000000000 represented a complete (5 minutes) of music, or just a very small sample and, equally importantly, whether the actual number and distribution of 0000's before and after the musical data was significant. I am now working on the basis that this is a very very small "sample" of the music, which has to be delivered at a very, very precise time. The 0000's control the very, very precise time ?

 

I think Simon is just giving a simplified version (0000abcdefghijklmnop000000000000000) because if he showed the full track of music, 42430128 bites of data would make a very long and tedious read, and might even be in breach of copyright.

Hi Chris (and others)

I wasn't criticising Simon on his example. In fact I found it a very useful example. And I certainly didn't expect Simon, or anybody else, to show the full detailed track of music, all 42,430,128 bites of it !!!!

But i'm still not exactly clear what those 0000's at the start and end of Simon's example actually represent. And more importantly, how they might affect the sound quality if the ripper doesn't copy them accurately.

Don, I'm in much the same place as you, trying to decide what the zeros at the start and finish of the track mean, and why, if there are 50000 or so at the start, the rip would add an extra 240. In my ignorance, I would assume this was just silence, and that the silence would just last a tiny bit longer, but no doubt it isn't as simple as that. Maybe the timing is out by 240 bytes, but if I speculate any more, I'm just going to look like even more of an idiot, so I'll leave it at that!

it sure as simple as that - if it is a little longer at the start - then it is a little shorter on the lead out at the end - the overall lengths are the same. If the audio file completely filled the track - such as a gapless track - then there might a truncation of 2.72mS as the offset I measured was 240 samples. In the example I analysed one rip would have 2.72mS less silence at the start and 2.72mS extra silence at the end compared to the other rip.

Yes the 0's in my illustration were simply zero samples that appeared in the lead in and lead out of the rip I analysed. A gapless rip would have no 0's and would start with the abcdefgh..... which are the illustrative values I used to represent the samples of actual music.

If one searches back - I did something similar on this forum a few years back. Dbpoweramp and EAC  ripped identically with a given CDROM. However iTunes had an offset error for that CDROM and the start of some rips were briefly truncated by iTunes compared to the other two rippers

Thanks Simon. So if the track was gapless, there would have been 240 bytes of music missing? But in this case, there were plenty of 'spare' zeros at either end, so presumably, this can't explain any perceived sound quality issues?

i think so yes - but unless I can't confirm with the test files i was given

Adam Meredith posted:

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

I'm positive that the entire United Kingdom of Great Britain and Northern Ireland, along with the citizens of at least a healthy majority of the members of the Commonwealth of Nations, thank you for your service.

I am hearing "God Save the Queen" in my head as I type this.

Bart posted:

Adam Meredith posted:

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

I'm positive that the entire United Kingdom of Great Britain and Northern Ireland, along with the citizens of at least a healthy majority of the members of the Commonwealth of Nations, thank you for your service.

I am hearing "God Save the Queen" in my head as I type this.

Quite so. Why should anyone ever bother to read a whole thread? Give that man an MBE for services to obfuscating the truth....

ChrisSU posted:

Thanks Simon. So if the track was gapless, there would have been 240 bytes of music missing? But in this case, there were plenty of 'spare' zeros at either end, so presumably, this can't explain any perceived sound quality issues?

You can open the samples in a text editor: the first block of 02 sample A is 108002 characters long. The first block of 02 sample B is 108482 characters long. The first relevant (after the header) non-zero character in the first block of A is at position 106751. The first relevant non-zero character of B is at position 107231. If you put the cursor on position 107231 of the first block of B and delete backwards until you get to position 106751, you obtain a file that has the same max_framebuffer size of the A sample. I think that the two files should now be equivalent, sound quality wise. In principle, any difference in the first blocks can explain sound differences. One could write a player that reads the first block and behaves differently if it meets certain conditions.

HoistTec posted:

I dont know the sound of the serve But i am really impressed by the core. The first 200 hours of playing it was really DIssapointing. I could not believe that a harddrive unit would need burn in. But somehowe in my case it did.  I stil have Some serieus problems. If i put rips from my nas on in the download folder of the core, it only shows about 20 rips of the 300. As woon as i remove the rips out of the download folder of the core everything is normal again.

Try creating an 'MQ' folder on the Core's 'Downloads' folder. Then move your music into the MQ folder.

David Hendon posted:

Bart posted:

Adam Meredith posted:

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

I'm positive that the entire United Kingdom of Great Britain and Northern Ireland, along with the citizens of at least a healthy majority of the members of the Commonwealth of Nations, thank you for your service.

I am hearing "God Save the Queen" in my head as I type this.

Quite so. Why should anyone ever bother to read a whole thread? Give that man an MBE for services to obfuscating the truth....

Well, I would expect those who decide to shud down a whole thread to have read that thread. Otherwise, following your reasoning, they could as well shut down the whole forum or the whole internet because of a few offending posts.

nbpf posted:

David Hendon posted:

Bart posted:

Adam Meredith posted:

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

I'm positive that the entire United Kingdom of Great Britain and Northern Ireland, along with the citizens of at least a healthy majority of the members of the Commonwealth of Nations, thank you for your service.

I am hearing "God Save the Queen" in my head as I type this.

Quite so. Why should anyone ever bother to read a whole thread? Give that man an MBE for services to obfuscating the truth....

Well, I would expect those who decide to shud down a whole thread to have read that thread. Otherwise, following your reasoning, they could as well shut down the whole forum or the whole internet because of a few offending posts.

Yes that's my point exactly....

nbpf posted:

Well, I would expect those who decide to shud down a whole thread to have read that thread. Otherwise, following your reasoning, they could as well shut down the whole forum or the whole internet because of a few offending posts.

I imagine those who actually decided to shut down the thread did read it.

I don't have that power - so I reported it.

Please read before becoming incensed.

David Hendon posted:

nbpf posted:

David Hendon posted:

Bart posted:

Adam Meredith posted:

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

I'm positive that the entire United Kingdom of Great Britain and Northern Ireland, along with the citizens of at least a healthy majority of the members of the Commonwealth of Nations, thank you for your service.

I am hearing "God Save the Queen" in my head as I type this.

Quite so. Why should anyone ever bother to read a whole thread? Give that man an MBE for services to obfuscating the truth....

Well, I would expect those who decide to shud down a whole thread to have read that thread. Otherwise, following your reasoning, they could as well shut down the whole forum or the whole internet because of a few offending posts.

Yes that's my point exactly....

I see, thanks for making the point! Hopefully we will soon get some official explanation of the reasons why the  thread has been closed and of the reasons why the Core and the US rips are different and whether this is to be expected or not.

Adam Meredith posted:

nbpf posted:

Well, I would expect those who decide to shud down a whole thread to have read that thread. Otherwise, following your reasoning, they could as well shut down the whole forum or the whole internet because of a few offending posts.

I imagine those who actually decided to shut down the thread did read it.

I don't have that power - so I reported it.

Please read before becoming incensed.

I know that you just reported it. Reporting a post is something different from shutting down a whole thread. I do not know who decided to close the thread and, to be honest, I do not care. They might have had very good reasons to do so or perhaps not. It's just that I expect them to have read the whole thread before shutting down the whole thread. Best, nbpf

Simon-in-Suffolk posted:

it sure as simple as that - if it is a little longer at the start - then it is a little shorter on the lead out at the end - the overall lengths are the same. If the audio file completely filled the track - such as a gapless track - then there might a truncation of 2.72mS as the offset I measured was 240 samples. In the example I analysed one rip would have 2.72mS less silence at the start and 2.72mS extra silence at the end compared to the other rip.

Yes the 0's in my illustration were simply zero samples that appeared in the lead in and lead out of the rip I analysed. A gapless rip would have no 0's and would start with the abcdefgh..... which are the illustrative values I used to represent the samples of actual music.

 

If one searches back - I did something similar on this forum a few years back. Dbpoweramp and EAC  ripped identically with a given CDROM. However iTunes had an offset error for that CDROM and the start of some rips were briefly truncated by iTunes compared to the other two rippers

Thank you Simon.

Just to be clear,

was the only difference between the RIPs that you analysed the length of the start and stop 0000's ?

if so, did this affect the Sound Quality of the abcdefg........ in some way ? (ie the music) 

Don, yes it literally was the only difference I found.. I didn't assess SQ other than casually and they both sounded the same to me.. others reported a difference when read by a disk player , but not when sent by UPnP... I suspect if there was a difference it would be some sort of wierd  coupling with interaction of disc reads for a given block of data sounding different compared to an offset block of data.. i.e. It's probably system related for a given rip rather than rip related per se...

Is there a way of editing the offset manually within a ripped (copyright free) file?

Just thinking that if the offset might be doing something weird, then it should be possible to do the listening test again with equalised offsets to confirm/disconfirm other reasons for any differences.

Dave***t posted:

Is there a way of editing the offset manually within a ripped (copyright free) file?

Just thinking that if the offset might be doing something weird, then it should be possible to do the listening test again with equalised offsets to confirm/disconfirm other reasons for any differences.

I think that was what NBPF was referring to in his reply, 8 or 9 posts back, so I guess it could be done.