[DONE] Sega Dreamcast: Multi-Cue > GDI
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
A separator is not really needed. Anything between "REM" and traling "START LBA NUMBER" is to be treated as a plain comment or a COMMAND, which will be recognized if its called "SESSION NUMBER" or "LEAD-IN" or "LEAD-OUT" or whatever commands you want to have there.
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
SINGLE-DENSITY AREA always starts at 0, HIGH-DENSITY AREA always starts at 45150, additional commands aren't needed here. These are to be discussed later for the multisessional discs (though, even they should have REM LEAD-OUT and REM LEAD-IN generating commands, not that LBA thing).
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
You know that they start there because you are aware of that, but mounting tools do not know it.
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
F1ReB4LL wrote:SINGLE-DENSITY AREA always starts at 0, HIGH-DENSITY AREA always starts at 45150, additional commands aren't needed here. These are to be discussed later for the multisessional discs (though, even they should have REM LEAD-OUT and REM LEAD-IN generating commands, not that LBA thing).
Yeah, but anyway: REM NAME / START LBA is also a new implementation that isn't supported yet by any software.iR0b0t wrote:You know that they start there because you are aware of that, but mounting tools do not know it.
If you want to assign a unique command for dreamcast discs that assumes fixed starting positions, then maybe 'LDA' and 'HDA' are better names.
Last edited by Jackal on Tue Dec 25, 2018 8:31 am, edited 1 time in total.
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
So what? Your "START LBA"/"START MSF" commands won't teach the mounting tools to do that, you need to tell the devs to code the support. So they can simply write the code to put the "REM HIGH-DENSITY AREA" data at 45150. You're overcomplicating things.
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
If there's no agreement on the single cue format, do the 2xcues with no additional tags. Easy.
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
"REM HIGH-DENSITY AREA" would be dreamcast exclusive, a global command would make more sense imho.
2xcues would be still dreamcast exclusive (without further REM commands)
2xcues would be still dreamcast exclusive (without further REM commands)
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
I think it should start with a real command and require input of a number, for uniformity and to allow other uses besides dreamcast.iR0b0t wrote:A separator is not really needed. Anything between "REM" and traling "START LBA NUMBER" is to be treated as a plain comment or a COMMAND, which will be recognized if its called "SESSION NUMBER" or "LEAD-IN" or "LEAD-OUT" or whatever commands you want to have there.
REM <COMMAND> <OPTIONAL DESCRIPTION> <START LBA NUMBER>
REM AREA "SINGLE-DENSITY" 45150
or
REM START "SINGLE-DENSITY AREA" 45150
Where the " " are optional and the last number is assumed to be the start address?
Last edited by Jackal on Tue Dec 25, 2018 8:50 am, edited 1 time in total.
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
Honestly, I would be fine with what you suggest @F1ReB4LL but in the end the emulaton / mounting devs have to adapt their tools to that. Independently of what they would accept, if I developed such a tool myself I would rather prefer a global command which can be used on any system, not just one.
Let the devs know and arrange an adaptation, if they decided something I will go by that, its not a big deal.
Let the devs know and arrange an adaptation, if they decided something I will go by that, its not a big deal.
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
Re: [DONE] Sega Dreamcast: Multi-Cue > GDI
See my previous post. I agree it would be best to implement a global command. What do you think about my suggestion?iR0b0t wrote:Honestly, I would be fine with what you suggest @F1ReB4LL but in the end the emulaton / mounting devs have to adapt their tools to that. Independently of what they would accept, if I developed such a tool myself I would rather prefer a global command which can be used on any system, not just one.
Let the devs know and arrange an adaptation, if they decided anything I will go by that, its not a big deal.
Last edited by Jackal on Tue Dec 25, 2018 8:43 am, edited 1 time in total.