"ii.) The third problem was small changes in synchrony between A and B, due to a pseudorandom dropping of 2 ms chunks of data on either side. Over the course of a 10 minute conversation, these could accumulate to a differential of 30 or 40 msec between sides--enough to change a cross-channel echo from inaudible to audible, for example, or from barely audible to very noticeable, for a human listener.
When this bug was finally run down, it turned out to be a piece of code in the utility which extracts conversations ('messages') from the Robotoperator message master file. The code performed a check at each data block boundary to see if the first two bytes had the values 'FF FF'; if so, these were interpreted as header information, and the 16 bytes beginning with "FF FF" were discarded as not part of the speech data. This code was a relic from an earlier version of the Robotoperator which did not deal with mu-law values, and thus never encountered FF in data. In mu-law data, FF is one of two ways of representing zero signal level ('minus zero'). The offending lines of code were removed and the problem ceased."
That corpus was frequently used some time ago for performing automatic speaker recognition tests/system evaluations.
Today, however, there are more challenging corpora, like those provided by NIST for its bi-annual speaker recognition evaluations (http://www.nist.gov/itl/iad/mig/sre10.cfm). These provide more mismatch conditions which require more advanced channel compensation mechanisms.
It seems, unfortunately, that the recordings aren't publicly available, although archive.org seems to have small sample of the transcripts: http://www.archive.org/details/SwitchboardCorpusSample
One particularly interesting section of the above readme was the section on technical issues (http://www.ldc.upenn.edu/Catalog/readme_files/switchboard.re...) including this example:
"ii.) The third problem was small changes in synchrony between A and B, due to a pseudorandom dropping of 2 ms chunks of data on either side. Over the course of a 10 minute conversation, these could accumulate to a differential of 30 or 40 msec between sides--enough to change a cross-channel echo from inaudible to audible, for example, or from barely audible to very noticeable, for a human listener.
When this bug was finally run down, it turned out to be a piece of code in the utility which extracts conversations ('messages') from the Robotoperator message master file. The code performed a check at each data block boundary to see if the first two bytes had the values 'FF FF'; if so, these were interpreted as header information, and the 16 bytes beginning with "FF FF" were discarded as not part of the speech data. This code was a relic from an earlier version of the Robotoperator which did not deal with mu-law values, and thus never encountered FF in data. In mu-law data, FF is one of two ways of representing zero signal level ('minus zero'). The offending lines of code were removed and the problem ceased."