the trackcount:
| 12 |
This is easy to get, but - what a pity - not the best decision.
A CD with 0 tracks isn't of much sense. The suffix '00' is therefor impossible and wasted.
In a million CD's there was no CD, having more than 99 tracks.
Probably it's not allowed or possible.
The highest suffix for a CSID is therefore '63' (16*6 + 3 = 99) - only 99 of 256 possible values are used.
62% of all possible, 8-digit hexadecimal number can't be generated.
And let's see further:
A good hashcode leads to equal disturbed bits on every position. i.e.:
If you take a sample (let's sayr 1000 CDs) by random, and generate a CSID for each, and count, how often each bit is set in the hashcode, every bitposition should match about 500 times 1 and 500 times 0.
A equal distribution can be generated by throwing a dice, and counting the numbers 1-6.
But the normal case in distributions is - the name suggests it - the normal-distribution.
You can get one, by throwing two dices, and counting the sums of both dice.
Since you may reach a sum of 7 on many ways (1+6, 2+5, 3+4, 4+3, 5+2, 6+1), a sum of 11 (6+5, 5+6) only by few, very rar the sums 12 (6+6) and 2 (1+1) - some values occur often, some rarely.
This is true for the trackcount too. On 1,06 Mio. CDs, 12 Tracks show up 100.000 times, 87 tracks only 8 times.
In a table-form for some values you get this picture:
| tracks | count |
|---|---|
| 1 | 6025 |
| 2 | 16363 |
| 3 | 26655 |
| 10 | 96821 |
| 11 | 76873 |
| 12 | 107077 |
| 13 | 67066 |
| 14 | 77278 |
| 30 | 2612 |
| 50 | 250 |
| 70 | 59 |
| 90 | 21 |
| 99 | 380 |
The high value at 99 tracks might be a result of the value being the possible maximum, and a lot of producer trying to put 'as much as possible' on the medium.
But added together, only 10349 CDs have more than 31 tracks.
This is 1% of the whole collection.
Therefore the upper 3 bits aren't set in 99% of the cases - this are hex-codes bigger than 'x1f' or from 'x20'
That means, 7/8 of the hashcodes are more or less thrown away, in 1/8 of the hash-room live 99% of the CDs.
the runtime:
| 1017 |
The runtime (in seconds) forms the middle, wide part of the hashcode.
In our example, 0x1017 - a decimal value of 4119 sec., which is about 69 min.
Here is a table of the number of occurences in whole minutes in the CD-population:
(Only exactly 10 min. shown here, and the last 3 values).
| minutes | count |
|---|---|
| 0 | 64 |
| 10 | 3681 |
| 20 | 5156 |
| 30 | 6513 |
| 40 | 19616 |
| 50 | 21807 |
| 60 | 21372 |
| 70 | 22518 |
| 80 | 1176 |
| 90 | 12 |
| 100 | 3 |
| 110 | 0 |
| 150 | 1 |
| 200 | 0 |
| 250 | 0 |
| 300 | 1 |
| 541 | 1 |
| 542 | 1 |
| 3591 | 1 |
The last value, which means a runtime of ca. 60 hours [sic!], is surely wrong.
What's about runtimes of 81 min. and above? Are this CD collections of 2 or more phyisical disks, or are the values simply wrong - I didn't investigate on this - they don't play an important role in the whole population.
Together only 692 CDs think of themself, to be 81 min. or more, which is less than 0,1%.
99,9% of all CDs use 7,4% of the 4-bit substring of the hashcodes.
92,6% of all possible values aren't used at all - or aren't used allmost all.
Combining this with the observation, that only 1/8 of the lower 2 hexcodes are used, we have a real usage of the hashroom of only 1%.
It's getting time to ask ourself, how big this hashroom is.
Theoretically you may put about 4.3 billion (am.) (=4.3 Mrd. european) different numbers into an 8-digit hexcode.
Praktically we only have 1% of this, which means about 40 Mio. numbers.
At todays about 1 Mio. CD's, there is some Room left.
We could now start a calculation, how many new CDs arise, and how many will arise in future.
This isn't that easy, because we may not easily make a linear approach.
The number of internet-users is growing progressiv.
The number of new CDs per month might be growing.
The number vinyl-LPs, which are converted to cd, should be sinking.
How long will it take, until CDs are vanishing?
Who is able to make a good suggestion is invented to do so.
SQS
| 11 |
'SQS' is my acronym for 'Summe of cross sums (Quersummen) of trackoffsets'. Thanks to dict.leo.org
That's how it works:
Every track has a starting position.
Divided by 75, we get the start-position in seconds.
For each seconds-offset we build the cross sum.
The cross-sums get added.
The result we calculate modulo 255.
The modulo-operation shall prevent the overrun of the numbers, but is fizzled here.
The value should have been taken modulo 256, and would then produce a maximum of '0xff'.
Here we get a maximum of '0xfe'. Compared to the misfits above, this one is rather small: we loose only 1/256 of possible values, but consequently.
In ca. 3/4 of all cases the first track starts at position 150 which is 2 seconds.
With ripped CDs you could use a trick, and simply add the 2 seconds for each first track.
This trick is widely used. (link: ...)
Unfortunly this is wrong in 1/4 of all cases.
Example:
| Startpos | in sec. | cross sum |
|---|---|---|
| 150 | 2 | 2 |
| 14177 | 189 | 18 |
| 28925 | 385 | 16 |
| 44671 | 595 | 19 |
| 67655 | 902 | 11 |
| 81235 | 1083 | 12 |
| 97467 | 1299 | 21 |
| 113562 | 1514 | 11 |
| 121176 | 1615 | 13 |
| 141939 | 1892 | 20 |
| 156423 | 2085 | 15 |
| 180203 | 2402 | 8 |
| 198065 | 2640 | 12 |
| 221472 | 2952 | 18 |
| 238963 | 3186 | 18 |
| 257836 | 3437 | 17 |
| 272925 | 3639 | 21 |
| 293785 | 3917 | 20 |
| sum_quersum | 272 | |
| sqs mod 255 | 17 |
Remembering the distribution of total lengths of CDs, with mostly total lentgths of 30 - 80 minutes:
These are 1800 to 4800 seconds, 4-digit decimals.
The last 3 digits should be equal distributed over the spectrum of ciphers/ all values from 0-9 should occur equal often - with an average of 4.5 .
The first digit should mostly be between 1 and 3, (100-399 seconds per track) sometimes 4, with an average around 2.
For 4-digit Numbers you get an average cross-sum of 15.5 .
Off course the first songs have smaller offsets - mostly of 3 digits.
Their average might be at 3*4.5 = 13.5 .
A very lazy calculation: I take an average of 15 and multiply with trackcounts of 10 - 20, so I end with SQS-values of 150 to 300.
modulo-255 I get values from 150-254 and 0-45, and a whole between 45 and 150.
Since this are very raw guessed values, and small distinctions have big effects:
(Trackoffset 1299-> cross sum=21, Trackoffset 1300-> cross sum=4)
... this isn't that critical like the value-discrimination at trackcount and total length.
Graphical view on hash-room - usage
- Logarithmic view
This is a snapshot of the programm - or better expressed as a forks of the programm, which calculates the count of hits for every single bit of the hashcode.
The snapshot is marked with comments afterwards.
In the left part, the original-hashcode is made visible, in the right one, my brandnew llci.
The bits 0-31 are printed left to right (big endian :).
The lower 8 bits are printed yellow, the mids 16 blue, and the upper 8 green.
The coloring was used accordingly for the llci, while here the distinction has no sense.
On the y-axis, the dots going down are a measuring for the number of hits.
Obvious is the Oszillation of the CSID-graph, where you have to keep in mind, that an additional dot might mean: doubleing the number of hits. (Of course because of rounding, - z.B. 255: 7 dots, 256 8 dots, one dot difference might only mean a difference of one as well.)
Here a graphic in linear form:
Punkte Treffer 1 1 2 2 3 4 4 8 ... ... 15 32768 ... ... 19 524288 - Linear view
-
As above: bits from left (0) to right (31).
Obvious: Differences at the CSID-bits.
You see too: the upper bits of the llci are less often hit than the lower ones.
The differences from the expected value (530.000 counts) keep civil.