bugCompact Disc Input and Control Library - Bugs: bug #46724, It seems that Mode1/2 reading...


bug #46724: It seems that Mode1/2 reading routines in win32_ioctl.c are somewhat inverted/incorrect.

Submitted by:  Aybe <aybe>
Submitted on:  Sun 20 Dec 2015 05:53:17 AM UTC  
Category:  API Severity:  5 - Average
Item Group:  libcdio Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 27 Dec 2015 06:36:04 AM UTC, comment #5:

This package is much better as a result of lots of people like you how in the past have contributed to it.

If there are patches to ease getting this to work on Windows better and they are portable - people sometimes offer patches that make their environment work at the expense of some or all of the others - then lets get them back in.

Likewise if you do get such a mode guessing routine coded and want to put it into libcdio, that would be most welcome too.

It would helpful just to get your compilation of libcdio into https://github.com/Alexpux/MSYS2-packages)


Rocky Bernstein <rocky>
Project Administrator
Sun 27 Dec 2015 05:47:58 AM UTC, comment #4:


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 !

Aybe <aybe>
Thu 24 Dec 2015 01:39:57 PM UTC, comment #3:

Here is a suggestion for how to decide on the calling side. The XA header has error correction information. So assume XA and see if there are lots of errors. If so, then the format is probably non-XA.

Down the line, we could to add as mode-guessing routine in libcdio. But that is not likely to happen unless someone other than myself is interested doing the bulk of the work.

Rocky Bernstein <rocky>
Project Administrator
Thu 24 Dec 2015 12:31:25 PM UTC, comment #2:

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 !

Aybe <aybe>
Thu 24 Dec 2015 03:17:26 AM UTC, comment #1:

Couldn't the problem be on the caller side rather than the libcdio side? I suspect the caller should be passing CDIO_READ_MODE_M1F2 instead of CDIO_READ_MODE_M2F2.

All libcdio is doing is interpreting the data based on how it was told to interpret the data. I believe both of these follow the specification for the given mode.

Rocky Bernstein <rocky>
Project Administrator
Sun 20 Dec 2015 05:53:17 AM UTC, original submission:

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

Aybe <aybe>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rocky (Posted a comment)
  • -email is unavailable- added by aybe (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.3