[Request] Please add multisession information to comments, for MS discs. #412

Closed
opened 2026-01-29 16:16:02 +00:00 by claunia · 7 comments
Owner

Originally created by @sadikyo on GitHub (Mar 3, 2022).

Originally assigned to: @mnadareski on GitHub.

Is your feature request related to a problem? Please describe.
When multisession discs are submitted, mods need to inspect the logs manually to determine and share the sessions for multisession in the comments.

Describe the solution you'd like
If MPF could calculate and automatically store this information in the comments, this would be very helpful.

Describe alternatives you've considered
Mods continuing to do this manually.

Additional context
Here is an example:
http://redump.org/disc/90453/
You can see the two sessions recorded in the comments under the Multisession heading.

Essentially, the two tracks are stored in the TOC info of _disc.txt, but a calculation has to be done.
For the first session, 11400 is subtracted from the end of the first track, to determine the sectors for session one. In this example, it shows 13836 sectors, so by subtracting 11400, you get 2436. Therefore, Session 1: 0-2435
Session 2 should be as shown in the TOC in disc.txt. Session 2: 13836 - 15099.

In this example, you can confirm this by the number of sectors shown in each track on the redump page. Essentially, there is a 11,400 sector "gap" that DIC stores as part of the first track, that should be parsed out here.

If there is any way for this to be done at the MPF level automatically with dumps, this would save a lot of post-work for mods.

Please reach out with any questions!

Originally created by @sadikyo on GitHub (Mar 3, 2022). Originally assigned to: @mnadareski on GitHub. **Is your feature request related to a problem? Please describe.** When multisession discs are submitted, mods need to inspect the logs manually to determine and share the sessions for multisession in the comments. **Describe the solution you'd like** If MPF could calculate and automatically store this information in the comments, this would be very helpful. **Describe alternatives you've considered** Mods continuing to do this manually. **Additional context** Here is an example: http://redump.org/disc/90453/ You can see the two sessions recorded in the comments under the Multisession heading. Essentially, the two tracks are stored in the TOC info of _disc.txt, but a calculation has to be done. For the first session, 11400 is subtracted from the end of the first track, to determine the sectors for session one. In this example, it shows 13836 sectors, so by subtracting 11400, you get 2436. Therefore, Session 1: 0-2435 Session 2 should be as shown in the TOC in disc.txt. Session 2: 13836 - 15099. In this example, you can confirm this by the number of sectors shown in each track on the redump page. Essentially, there is a 11,400 sector "gap" that DIC stores as part of the first track, that should be parsed out here. If there is any way for this to be done at the MPF level automatically with dumps, this would save a lot of post-work for mods. Please reach out with any questions!
claunia added the enhancement label 2026-01-29 16:16:02 +00:00
Author
Owner

@mnadareski commented on GitHub (Mar 3, 2022):

As noted elsewhere, the work for this will be split into 2 parts:

  1. Add the multisession data as a new pseudo-tag so it can be represented internally and shown in the read-only data
  2. Add the parsing and population functionality from the DiscImageCreator outputs
@mnadareski commented on GitHub (Mar 3, 2022): As noted elsewhere, the work for this will be split into 2 parts: 1. Add the multisession data as a new pseudo-tag so it can be represented internally and shown in the read-only data 2. Add the parsing and population functionality from the DiscImageCreator outputs
Author
Owner

@sadikyo commented on GitHub (Mar 3, 2022):

Some additional info:

Planet DC Cheats Band 3_disc.txt

Here is an example of a _disc.txt file for a simple case with only one track in each session.

  1. You can see the "gap" toward the bottom, as follows;
    Set OpCode: 0xd8, SubCode: 8(Raw)
    Lead-out length of 1st session: 6750
    Lead-in length of 2nd session: 4500
    Pregap length of 1st track of 2nd session: 150

Total of above is the 11,400 gap.

If you look at the TOC toward the top:
========== TOC ==========
Audio Track 1, LBA 0 - 13835, Length 13836
Data Track 2, LBA 13836 - 15099, Length 1264
Total 15100

It shows total sectors as 15100, but it stores the first track incorrectly (it adds the 11,400 gap to the first track)

First session is not 13836 sectors, but only 2436 sectors (13836 - 11400). Therefore, session one is 0 - 2435.
Second session is 1264 sectors, and listed correctly above, as 13836 - 15099.

@sadikyo commented on GitHub (Mar 3, 2022): Some additional info: [Planet DC Cheats Band 3_disc.txt](https://github.com/SabreTools/MPF/files/8181396/Planet.DC.Cheats.Band.3_disc.txt) Here is an example of a _disc.txt file for a simple case with only one track in each session. 1. You can see the "gap" toward the bottom, as follows; Set OpCode: 0xd8, SubCode: 8(Raw) Lead-out length of 1st session: 6750 Lead-in length of 2nd session: 4500 Pregap length of 1st track of 2nd session: 150 Total of above is the 11,400 gap. If you look at the TOC toward the top: ========== TOC ========== Audio Track 1, LBA 0 - 13835, Length 13836 Data Track 2, LBA 13836 - 15099, Length 1264 Total 15100 It shows total sectors as 15100, but it stores the first track incorrectly (it adds the 11,400 gap to the first track) First session is not 13836 sectors, but only 2436 sectors (13836 - 11400). Therefore, session one is 0 - 2435. Second session is 1264 sectors, and listed correctly above, as 13836 - 15099.
Author
Owner

@mnadareski commented on GitHub (Apr 12, 2022):

Pseudo-tag added in e5154dad5b

@mnadareski commented on GitHub (Apr 12, 2022): Pseudo-tag added in https://github.com/SabreTools/MPF/commit/e5154dad5b745ecdfcb97f2402b013ceb452f763
Author
Owner

@mnadareski commented on GitHub (Apr 12, 2022):

I've been looking this over and I don't fully understand how it's determined what tracks fall into what session based on the _disc.txt file. Can you possibly provide the outputs of a multisession disc with more than 2 tracks?

@mnadareski commented on GitHub (Apr 12, 2022): I've been looking this over and I don't fully understand how it's determined what tracks fall into what session based on the `_disc.txt` file. Can you possibly provide the outputs of a multisession disc with more than 2 tracks?
Author
Owner

@Feathered-Serpent commented on GitHub (Apr 12, 2022):

I'm not OP though I thought I can share examples. One from a PSX game, which has lots of audio tracks (though I think these are all within one session), one of a EnhancedCD (aka Audio CD with Data track) which are definitely two sessions.
EnhancedCD.txt
PSX.txt

Thought maybe they can help.

@Feathered-Serpent commented on GitHub (Apr 12, 2022): I'm not OP though I thought I can share examples. One from a PSX game, which has lots of audio tracks (though I think these are all within one session), one of a EnhancedCD (aka Audio CD with Data track) which are definitely two sessions. [EnhancedCD.txt](https://github.com/SabreTools/MPF/files/8476363/EnhancedCD.txt) [PSX.txt](https://github.com/SabreTools/MPF/files/8476364/PSX.txt) Thought maybe they can help.
Author
Owner

@mnadareski commented on GitHub (Apr 12, 2022):

Implementation notes:

  • Parse out the TOC section at the top and store the values, just in case
  • Read in the entire FULL TOC section and map the previous TOC data to the Sessions
  • If they're all in the same session, then there's no multisession
  • If there are multiple sessions, read down to right before "Lead-out length of 1st session" and "Pregap length of 1st track of 2nd session" and get those bits
  • If we have everything we need, convert to int values to do math
  • If the conversions worked, do the math required and format the data
@mnadareski commented on GitHub (Apr 12, 2022): Implementation notes: - Parse out the TOC section at the top and store the values, just in case - Read in the entire FULL TOC section and map the previous TOC data to the Sessions - If they're all in the same session, then there's no multisession - If there are multiple sessions, read down to right before "Lead-out length of 1st session" and "Pregap length of 1st track of 2nd session" and get those bits - If we have everything we need, convert to int values to do math - If the conversions worked, do the math required and format the data
Author
Owner

@mnadareski commented on GitHub (Apr 12, 2022):

Another note: The Enhanced CD example above does not have the line that says "Lead-in length of 2nd session". So that part is variable.

@mnadareski commented on GitHub (Apr 12, 2022): Another note: The Enhanced CD example above does _not_ have the line that says "Lead-in length of 2nd session". So that part is variable.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SabreTools/MPF#412