Hello,

That makes sense and I'll give it a try.

Regarding help I would have loved to give a hand but so far it's been close to mission impossible for me to get libcdio to compile for Windows. The only way I found was to get binaries from tools from the Linux world (MSYS2). So having a decent workspace (IDE + debugger) is just not possible this way.

I somehow managed to get libcdio to compile in Windows by re-creating the MSVC solution and associated bits such as config.h and unistd.h but I've been granted by an elusive 'Internal Compiler Error' without the slightest hint of the cause (no error code at all) !

Anyway, I have enough bits to alleviate the issue with your suggestions now.

Thank you !

Well, I guess you're right.

Situation is a bit weird over here though: when I call 'cdio_get_track_format' on a PSX media, one would expect either 'TRACK_FORMAT_XA' or even better 'TRACK_FORMAT_PSX'.

However thus far, I haven't been able to get these out of a PSX media, only 'TRACK_FORMAT_DATA'. It's a bit strange since every software analyzing the disc will indeed see it as Mode 2.

So basically if I 'blindly trust' that value and read accordingly, problem is gone though I might have to re-interpret a bit the sector on my side, depending the task (regular file VS stream in Form2).

However, on a Linux build it is not the case, and passing M2F2 really does work :)

Going to try understand a bit more what's happening under the hood ...

Thanks for your help !

For the version 0.93 of the library,

Environment used:
Windows 10 64-bit, Visual Studio 2015, libcdio compiled from MSYS2 (  https://msys2.github.io/ and https://github.com/Alexpux/MSYS2-packages), using shared libraries generated as explained in https://wiki.videolan.org/GenerateLibFromDll

Problem description/solution:
=============================
When attempting to read a Playstation video file (with audio) using 'cdio_read_sectors' method with a parameter 'CDIO_READ_MODE_M2F2', produced output is invariably wrong as by looking at the bytes returned, synchronization headers are missing.

However, when changing the reading mode to 'CDIO_READ_MODE_M1F2' it produces a correct output.

By comparing the reading routines in win32_ioctl.c, bincue.c and nrg.c, the offset specified in the 'memcpy' operation in win32_ioctl.c is 'CDIO_CD_SYNC_SIZE + CDIO_CD_XA_HEADER' whereas on other files it is always 'CDIO_CD_SYNC_SIZE + CDIO_CD_HEADER_SIZE'; which results in  synchronization header not being returned before the real data.


These are my conclusions from that small investigation, unless I've mis-interpreted the correct usage of the API.

Thanks a lot for this fantastic library !

Best regards