We read the raw data from the disc,
extract the Q sub-channel and decode the ISRC.

This gives better results (no duplicate ISRCs)
than using the read ISRC sub-channel command.
Probably due to bad implementation on some drives / drivers.

I actually tried SEEK, READ (6), SCAN and also PLAY AUDIO
to move to some point more to the middle of the track in order
not to get an ISRC from the previous track.
None of these made any difference.

This should update the branch,
especially add the features API and the compiler warning fixes.

Conflicts:
	CMakeLists.txt
	configure.ac
	src/disc_linux.c

This is platform independent, except the call of scsi_cmd,
which is implemented for the platform.

We don't have to prepend every file with "disc",
even if they implement some type of disc reading.

Also separate scsi_cmd and scsi_cmd_unportable,
although there is only unportable code right now.

scsi_cmd_unportable not mandatory to implement for every platform,
so it is in this header and not discid_private.h
However, it is recommended to implement.

This should lower the chance of having a clash in the namespace.
This is not as important as in the public API,
but scsi.h is potentially included in many platform files.

After reading ISRCs the device keeps spinning, sometimes loudly.
Stopping the device helps with that.

This does have the side effect of stopping playback,
when the disc is played directly.

See:
http://tickets.musicbrainz.org/browse/LIB-31

This merges the read_sparse functionality,
lots of autotools changes, hiding of private functions in the library
and adds version defines.
LIBDISCID_INTERNAL was added to scsi.h manually.

Conflicts:
	configure.ac
	src/Makefile.am
	src/disc_linux.c

The CRCs are not used yet, but I wanted to mark the location.

This merges the two windows platform files.

Conflicts:
	CMakeLists.txt

This merges the data-track changes and removes Win9x code.

Conflicts:
	Makefile.am
	src/disc_linux.c

This mainly merges the new test suite.

Conflicts:
	Makefile.am

I implemented this from scratch.
This is probably not the most efficient implementation,
but the check doesn't even have a measurable impact.
We are reading data from disc and only check the CRC when an ISRC is
found, which is ca. every 100th frame.

The focus is a clear implementation without storing (CRC-8) tables in the code.

CRC mismatches are only printed to stderr for now.

Having memcheck in the branch would be nice.

Especially use defines for some magic numbers.

We read up to 3 ISRCs and use the first one where the CRC is correct.
A warning is printed to stderr when CRC mismatches are found.
We should probably skip the warning when these are very common.

This doesn't have an impact on the performance,
since the data is still read from disc, just not returned by the
command.
However, there seems to be a limit of data returned with one command.
My tests failed after reaching something over 683 KB.

This enables us to read data for up to 71 ISRCs,
but that would also take ca. 5 minutes per disc.

Setting this to 2, to tolerate one failed CRC check.

With this approach we read a lot less sectors when the ISRC is found
early, which saves a lot of time.
Additionally this does seem to have the side effect of drives returning
less CRC mismatches.

This isn't tested with a disc yet. Only compilation (cmake) is tested in a VM.

This still doesn't seem to work in MinGW and Cygwin.
discid_get_track_length can't be linked somehow.

CMake works fine.

Since we can't use any discid_* functions anywhere else other than in disc.c on Windows due to the __declspec(dllexport),
we have to move the code to some place where we can also access it internally.

It's just 4 lines, but we have to make sure both places use the same code. Otherwise we get weird issues.

Similar to ntddcdrm.h, this header is included in MinGW and Cygwin, but
has to be downloaded separately for plain Windows.
This would be part of the Windows Driver Development Kit (ddk),
but that version is probably not redistributable for us.

This version comes from dosbox again.

Sending scsi commands needs GENERIC_WRITE for the handle,
otherwise no data is returned.

For DeviceIoControl a return value of 0 is the error condition,
while the return value of scsi_cmd is expected to be 0 on success.

We now return the scsi status as we do in Linux.

0 is actually success, since that is the scsi status code for success.

Also make explicite that -1 is the error condition for ioctl.

This should handle cases where no actual error is reported,
but other things are fishy.

When no ISRCs are present (valid CRC or not) in the first 100 sectors
(150 to be safe), there are no ISRCs on the track at all
so we stop searching.

Otherwise we would search the whole track, which then takes like 5
minutes per disc.

Reading more sectors takes more time.
10 more would be 10% more, rather than 50%.
This should be fine.

This was already fixed a month ago,
but the unfixed commit was in the main repo.

This way we don't have to cast between HANDLE (void *)
and int.
We might need a third handle for OS X later on.

This adds raw isrcs reads on Windows.

Conflicts:
	src/disc_linux.c
	src/scsi.h

This hopefully enables us to catch some conditions
when raw reading doesn't work.

This works, but actively checking for raw ISRC support might be better.
There are error messages displayed for every track,
when raw ISRC reads don't work.

Some SCSI commands are optional per MMC so we check
especially if raw ISRC reads are supported.

It is still unclear if there are devices that can read audio CDs,
but without CD READ support.
Reported problems might be unrelated.

This way it corresponds with the command name in scsi.h
The platform doesn't have to know how non-raw isrc reads work.

this pulls the TOC API and a lot of default drive changes

Conflicts:
	src/disc.c
	src/disc_linux.c
	src/disc_win32.c

This should fix reading ISRCs on Windows again. (0.6.1)

Conflicts:
	src/disc_win32.c