Editing Group coded recording (section)

== {{anchor|Tape|IBM}}Magnetic tape ==
Group coded recording was first used for [[magnetic-tape data storage]] on [[9-track tape|9-track]] [[reel-to-reel tape]].<ref name="Patel_1988_MR" /> The term was coined during the development of the [[IBM 3420]] Model 4/6/8 Magnetic Tape Unit<ref name="CW_1973_IBM" /> and the corresponding [[IBM 3803|3803]] Model&nbsp;2 Tape Control Unit,<ref name="OldIron_2004_IBM3803" /><ref name="CW_1973_IBM" /> both introduced in 1973.<ref name="CW_1973_IBM" /><ref name="Harris_1981_IBM" /> [[IBM]] referred to the error correcting code itself as "group coded recording". However, GCR has come to refer to the recording format of {{val|6250|u=bpi}} (250&nbsp;bits/mm<ref name="Patel_1988_MR" />) tape as a whole, and later to formats which use similar RLL codes without the error correction code.

In order to reliably read and write to [[magnetic tape]], several constraints on the signal to be written must be followed. The first is that two adjacent [[flux reversal]]s must be separated by a certain distance on the media, defined by the magnetic properties of the media itself. The second is that there must be a reversal often enough to keep the reader's clock in phase with the written signal; that is, the signal must be [[self-clocking signal|self-clocking]] and most importantly to keep the playback output high enough as this is proportional to the density of flux transitions. Prior to {{val|6250|u=bpi}} tapes, {{val|1600|u=bpi}} tapes satisfied these constraints using a technique called [[phase encoding]] (PE), which was only 50% efficient. For {{val|6250|u=bpi}} GCR tapes, a (0,&nbsp;2)&nbsp;[[Run Length Limited|RLL]] code is used, or more specifically a <small>{{sfrac|4|5}}</small>&nbsp;(0,&nbsp;2) [[block code]]<ref name="Patel_1988_MR" /> sometimes also referred to as ''GCR (4B-5B)'' encoding.<ref name="Geoffroy_2002" /> This code requires five bits to be written for every four bits of data.<ref name="Patel_1988_MR" /> The code is structured so that no more than two zero bits (which are represented by lack of a flux reversal) can occur in a row,<ref name="Patel_1988_MR" /> either within a code or between codes, no matter what the data was. This RLL code is applied independently to the data going to each of the nine tracks.

Of the 32 five-bit patterns, eight begin with two consecutive zero bits, six others end with two consecutive zero bits, and one more (10001) contains three consecutive zero bits. Removing the all-ones pattern (11111) from the remainder leaves 16 suitable code words.

The {{val|6250|u=bpi}} GCR RLL code:{{r|Keong_GCR|Watkinson_1990|Savard_2006|Geoffroy_2002}}
{|
|
{|class="wikitable" style="text-align:center;"
! colspan="2"|4-bit value !! colspan="2"|GCR code{{r|Keong_GCR|Watkinson_1990}}
|-
! hex !! bin !! bin !! hex
|-
| 0x0 || 0000 || 1.1001 || 0x19
|-
| 0x1 || 0001 || 1.1011 || 0x1B
|-
| 0x2 || 0010 || 1.0010 || 0x12
|-
| 0x3 || 0011 || 1.0011 || 0x13
|-
| 0x4 || 0100 || 1.1101 || 0x1D
|-
| 0x5 || 0101 || 1.0101 || 0x15
|-
| 0x6 || 0110 || 1.0110 || 0x16
|-
| 0x7 || 0111 || 1.0111 || 0x17
|}
|
{|class="wikitable" style="text-align:center;"
! colspan="2"|4-bit value !! colspan="2"|GCR code{{r|Keong_GCR|Watkinson_1990}}
|-
! hex !! bin !! bin !! hex
|-
| 0x8 || 1000 || 1.1010 || 0x1A
|-
| 0x9 || 1001 || 0.1001 || 0x09
|-
| 0xA || 1010 || 0.1010 || 0x0A
|-
| 0xB || 1011 || 0.1011 || 0x0B
|-
| 0xC || 1100 || 1.1110 || 0x1E
|-
| 0xD || 1101 || 0.1101 || 0x0D
|-
| 0xE || 1110 || 0.1110 || 0x0E
|-
| 0xF || 1111 || 0.1111 || 0x0F
|}
|}
11 of the [[nibble]]s (other than xx00 and 0001) have their code formed by prepending the complement of the [[most significant bit]]; i.e. abcd is encoded as {{overline|a}}abcd. The other five values are assigned codes beginning with 11. Nibbles of the form ab00 have codes 11ba{{overline|a}}, i.e. the bit reverse of the code for ab11. The code 0001 is assigned the remaining value 11011.

Because the all-ones code is not used in normal data, at most 8 one-bits can appear in a row.  Sequences of 9 or more one-bits (in practice 14 all-ones codes, or 70 one-bits, were used) are used as a [[synchronization pattern]].

Because of the extremely high density (for the time) of {{val|6250|u=bpi}} tape, the RLL code is not sufficient to ensure reliable data storage. On top of the RLL code, an [[error-correcting code]] called the [[Optimal Rectangular Code]] (ORC) is applied.<ref name="Patel_1974_ORC" /> This code is a combination of a [[parity bit|parity]] track and [[polynomial]] code similar to a [[Cyclic Redundancy Check|CRC]], but structured for error correction rather than error detection. For every seven bytes written to the tape (before RLL encoding), an eighth check byte is calculated and written to the tape. When reading, the parity is calculated on each byte and [[exclusive-OR]]ed with the contents of the parity track, and the polynomial check code calculated and exclusive-ORed with the received check code, resulting in two 8-bit syndrome words. If these are both zero, the data is error free. Otherwise, error-correction logic in the tape controller corrects the data before it is forwarded to the host. The error correcting code is able to correct any number of errors in any single track, or in any two tracks if the erroneous tracks can be identified by other means.

In newer IBM half-inch 18-track tape drives recording at {{val|24000|u=bpi}}, <small>{{sfrac|4|5}}</small>&nbsp;(0,&nbsp;2) GCR was replaced by a more efficient <small>{{sfrac|8|9}}</small>&nbsp;(0,&nbsp;3) modulation code, mapping eight bits to nine bits.<ref name="Patel_1988_MR" />