Tricky cdrom image writing

[gidierre]

spinning off from this thread as subject changes (not really a strict TR1/dosbox issue)

To make a mixed-mode cdrom image (TRI & TRII are mixed-mode) in the cue/bin format (vs. iso, nrg, cdi, mds/mdf, ccd/img/sub etc.) so dosbox can read the image, not many programs are available, many can read/burn/convert this format, but not create it.
I considered good, old CDRWin (a shareware, and won't work with all cd/dvd burners), Alcohol 120% (shareware too) and ImgBurn (freeware)
decided to use Alcohol (functional demo) and ImgBurn and the .cue files were oddly different.
For some general info on cue specs, especially the Pregap and Index items
http://digitalx.org/cuesheetsyntax.php
http://www.pcnineoneone.com/howto/cdburnadv4.html

.cue made by Alcohol appears to be 4 seconds out of synch, ImgBurn is fine. How come?

Browse this interesting post

"As you can see, the games ripped with Alcohol have their audio tracks 2-seconds forward out of place...
when dumping a CD that contains data on the first track and audio on the following tracks (an old computer game is a good example), Alcohol will throw the audio tracks exactly 2-seconds out-of-sync.
This causes the first 2-seconds of a track to be played at the end of the track preceding it. By this, I mean that a song will start 2-seconds in, play through, get to the end (where a short silence is usually heard) and then instead of going to the next track like it normally should, the first 2 seconds of the next track play as if they are part of the song.
Then the next track will start seamlessly, except 2 seconds in, and this process continues throughout the whole CD.
To correct this, you have to edit the .CUE file created by Alcohol with Notepad and shave off 2 seconds from the middle set of digits of every track numbered #3 and onwards (track 1 is data, track 2 is audio but is always in sync). By doing this, the audio is set back into its original position and play's perfectly"

(or use ImgBurn cue which is alright )

that's precisely what's going on here.

I go test TR1 track #7, remembering that #1 is data (no music), #2 i.e. the spinning menu tune is in synch, #3+ are all misplaced.
#7 is played in Atlantis
from Stella's walkthrough:

Next, a cut scene: Lara staggers back from the altar and sees Natla draw near. "Back again?" Natla asks.
Lara returns, "And you?" Lara responds, "For a grand re-opening, I assume?"
...
Lara pulls up onto the platform below the incubator as the electronic voice counts down, "Five...four...three...two...one...."

that one. Using Alcohol's, after Natla plummets in the pitchy pit, Lara pulls through, countdown... then abruptly you hear the onset of track #8:

Well, you have my total attention now. I’m not quite sure if I’ve got yours, though
funny, huh?

Let's compare the 2 .cue files, thye're in simple text format

ImgBurn's on the left
Pregap looks right, then from track #3 on, all Index 0 instances are lost on Alcohol! Now Index 0 occurrences might as well be left out of a cue by design, since only Index 1 presence is necessary to play, but if the other program detects them...
Notice that always [Index 1] - [Index 0] = 00:02:00, that is 2 seconds,
in minutes/seconds/frames format, and a frame or sector is 2,352 bytes and makes for 1/75th of a second of playing music (1 second = 75 frames = 176,400 bytes).
If Index 0 is missing, when the other detects it, woe to synch! But let's probe a little further.

Use the nice freeware CDmage, joining the output of the couple of cues' examination
ImgBurn on top, Alcohol below

trying to focus on what I tried to emphasize with some pathetic colored framings, 4 seconds = 300 sectors = 700,560 bytes are misplaced
the whole cdrom size appears to be 389,752,271 bytes, so the displacement's reach is almost 0.18% of it altogether. No wonder it's pretty sensible. Like if I ride around the world all along a meridian and fall short by 70 km. or so.

in red lines, see the pause [Index 0] detection flunk in Alcohol, which itself accounts for messing up 150 sectors (2 secs) since tracks #3+ get shoved that much forwards

in yellow and blue, track size (in bytes and in sectors as well) is OK, but start & end sectors are resp. 150 and 300 frames off
obviously pause is lost, but pregap too must be going awry (the way I see it, it has to be read and added twice too many to start sector for a 300 frame blooper to occurr)

in black ellypsis, 4 seconds are appended to track #2, compare its size and end sector figures too--ironically, this tune, the sweet melody of the TR menu, is the only one that's played right anyway (even if cue by Alcohol is burned): of course, start sector's fine for it

in violet playpen, after all this 4 seconds haste, in the end the cdrom is no stretchable stuff is it, so last track size can't help but mysteriously shrink by 4 seconds

[Phys]

Interesting. Its typical that it was only one day ago I was having to deal with this myself and then you post it today

Yesterday I was dealing with this to try and come up with a way of making a mixed-mode bin/cue image to use with a virtual drive emulator. The reason for this is because the CD I was using has scratches on, and a certain track kept skipping every 5 seconds, in turn causing Tomb Raider to weirdly go x2 speed, then back to normal, then x2, then back to normal and etc each time the sound skipped.

In the end I managed to complete the level with the certain soundtrack anyway so it didn't matter. Thanks for posting though. Might come in handy in the future

[spikejones]

just thought i'd poke my head in here and suggest perhaps another app that may work - Infrarecorder

[gidierre]

thx I'll surely try that too and see if it makes .cue right like ImgBurn.

EDIT

tried
it's good, but won't write a cue/bin the way I want

while I was at it, took a BlindWrite demo too, and that too worked of course, its own way
but not the best imo for mixed-mode.

[gidierre]

after trying Infrarecorder and BlindWrite as reported in (editing of) previous post,
I went ahead and tried IsoBuster too, with imprecise results like Alcohol, but then IsoBuster's mission is to work on .iso files, not to create valid cue sheets is it

and finally Exact Audio Copy
this software is very nice, but apparently the mixed-mode format gets it into some trouble, maybe because its specs are no standard red book cdaudio only, so EAC falls short by 2 seconds, vs. 4" by Alcohol.

maybe this is kinda reasonable, since mixed-mode's track #1 is data, so the cdaudio music portion of cd (track #2+) is actually exposed correctly

while I showed Alcohol getting the Pause/Index 0 and the Pregap readings wrong, EAC has Indexes right, a good cdaudio extractor app it is,
but Pregap's not understood, so after all ImgBurn reading is the one and only accurate output we need
especially in case you want to mount/burn an image of the whole mixed-mode cd, rather than only the cdaudio tracks in it

a screenshot can help and I made another one (not a small one), comparing again 2 CDmage windows of ImgBurn vs. Alcohol cue (not the ones shown before) and in between the EAC window of my TR1 cdrom cue
http://img511.imageshack.us/img511/6047/eacvscdmage.jpg

a pattern can be seen, maybe not at a first glance, say at the fiftieth...
at the hundredth I could see anything in it, I guess

not to mention that what I think I see in it might well be far from correct
anyway this is how I did it:

Top: cue by ImgMount in CDmage (the right one)
Middle: cue by EAC (2 secs. wrong)
Bottom: cue by Alcohol in CDmage (4 secs. wrong)

Look at Track #10 row:
00:36:65 becomes 00:34:65 becomes 00:32:65

case closed? yes, but there's much more to be delved into here...

let's examine Track #2:
03:14:45 (Size MSF, top) becomes 03:16:45 (Length, middle) becomes 03:18:45 (Size MSF, bottom)

notice that Track #2 Length (EAC) can correctly compare to Size MSF (CDmage) only, certainly not to Total Time (CDmage):
in CDmage all the times Total Time = Size (MSF) except for Track #2 where Total Time is 2 seconds longer than Size MSF

now generally
Size MSF = Total Time = End Sector - End Sector of previous track
but not for Track #2 because there Pregap and Size MSF add up to Total Time, Pregap is padded between T. #1 End Sector and T. #2 Start Sector
so for Track #2 only it seems it should go like this:
Size MSF = End Sector - Start Sector
Total Time = End Sector - End Sector of previous track

Total Time = Size MSF + 150 = End Sector - Start Sector + 150
Q.E.D.
that's where Pregap butts in.

As already noticed in first post, Alcohol cue (bottom) would miss it big by 4 seconds too many vs. ImgBurn (top)
just see Track #2 figures for Start Sector/End Sector
87,433/102,027 vs. 87,433/102,327
300 sectors added at random, it's as if Pregap was erroneously counted twice more,
then as far as Track #3 and above are concerned, reckoning with the Pause commands is lost, but this can't alter their Size MSF/Total Time, it only cancels the pause.

And EAC?
EAC gets the Pregap wrong. 00:02:00 wrong. How can I tell?
Easy: look at EAC Track #2 Start (19:23:58) vs. Track #1 Length (19:23:58)
Correct? No way! Pregap's not allowed for.
Compare CDmage Track #1 Total Time (19:21:58) this is fine, add 150 (2 seconds) for Pregap and you'll get the Track #2 start right at 19:23:58. Isn't it just the same? Not at all, actually EAC is just lenghtening T. #1 duration by 2 seconds, including that Pregap time in T. #1 timing, that's what it really does and can never make up for it afterwards so all tracks ahead are pushed 2 seconds forward.

[gidierre]

sorry, I tried so hard and for so long, but I really just can't let this subject go until I somehow get off my chest some haunting technical considerations about this 150 magic number of sorts that like a writing on the wall lingers, although instead of a baffling Mene, Tekel and Peres inscription a much more vapid 150 figure recurs.

A 150 frame span hanging around adding up to correct timing or not.
I regret this being so mumbo jumbo, but I wouldn't know any other way to present it.
I come out with this technicality mostly to objectify it and to distance myself from it, so to speak, and also in the surely bumptious hope that sooner or later who knows someone may get an inspiration to delve further into the subject. That's what hypertexts are for, after all.

KMO released an outstanding Audiopack for Tomb Raider 1 that's been used by Glidos since. In his accompanying Release 1.10/ReadMe1st.html he wrote

"Known bugs and problems
•When running under Glidos with CD, I've found that there's a two-second silence before each track. I assume this is the pre-track gap; this doesn't happen with dgVoodoo/VDMSound(*). I assume this is a flaw in Glidos' MSCDEX emulation.
•You may hear a brief snippet of the next track after a track finishes.(**) On my Windows XP system, this is cured by turning off digital CD playback in the properties dialogue box for the drive in question. Turning this off will also significantly reduce average system load and thus may boost game performance on a slower machine. However, it may increase the the time that the game freezes at track changes."

(*) actually it's neither dgVoodoo nor VDMSound, but sapucdex (now ssdh) handling the 150 frame mismatch right
(**) that's it, but I guess it's not a matter of digital (vs. analog?) playback here, its rather a pregap's 2 secs misfire.

Alcohol's wrong cue readings reversed, kind of.

Here
http://vogons.zetafleet.com/viewtopic.php?t=249
you can get redbook.zip with redbook support source code used in Glidos, liberally shared by Paul Gardiner

peruse CDAudio.cpp, look up CCDAudio::start() together with CCDAudio::frames2msf(unsigned int f)
no 150 value is ever reentered/reclaimed here afaict

unsigned int CCDAudio::frames2msf(unsigned int f)
{
    unsigned int frames, seconds, minutes;

    frames = f;
    seconds = f / 75;
    frames -= seconds * 75;
    minutes = seconds / 60;
    seconds -= minutes * 60;

    return minutes | (seconds<<8) | (frames<<16);
}

void CCDAudio::start()
{
    MCIERROR err;
    MCI_PLAY_PARMS pparms;

    pparms.dwCallback = NULL;
    pparms.dwFrom     = frames2msf(m_start);
    pparms.dwTo       = frames2msf(m_start+m_duration);
    
    err = ::mciSendCommand(m_id, MCI_PLAY, MCI_FROM|MCI_TO, (DWORD) &pparms);
}

here's why, as noted by KMO, timing's out of sync, not adjusted.

What about dosbox way of handling it?
Here implementation, both in -ioctl and -noioctl mounting cases, will add 150 sectors to starting frame figure:

To be found in cdrom_ioctl_win32.cpp
(dosbox v0.73, for v 0.72 see here)

bool CDROM_Interface_Ioctl::PlayAudioSector (unsigned long start,unsigned long len) {
	if (use_mciplay) {
		if (!mci_CDPlay(start+150, len))	return true;

and in cdrom.cpp (0.72 source)

bool CDROM_Interface_SDL::PlayAudioSector (unsigned long start,unsigned long len) 
{ 
	....
	cd = SDL_CDOpen(driveID);
	bool success = (SDL_CDPlay(cd, start+150, len)==0);
	return success;
};

Finally, compare sapucdex/ssdh routines:
150 (as a MSF_OFFSET) gets added in INT2MSF function

#define CD_FPS	75
#define MSF_OFFSET	(2 * 75)	// offset of first cdrom sector (0:2:0)

// to avoid including cdrom.h and/or sdl_cdrom.h, write the macros here

#define MSF_TO_FRAMES(M, S, F)	((M)*60*CD_FPS+(S)*CD_FPS+(F))

#define FRAMES_TO_MSF(f, M,S,F)	{					\
	int value = f;							\
	*(F) = value%CD_FPS;						\
	value /= CD_FPS;						\
	*(S) = value%60;						\
	value /= 60;							\
	*(M) = value;							\
}


void INT2MSF(int i, MSF *msf) {
	i += MSF_OFFSET;			// here's when 150 gets added. 
	msf->frame = i % 75;
	i /= 75;
	msf->second = i % 60;
	msf->minute = i / 60;
}

applied to start frame location in DevPlayAudio()

	INT2MSF(start_loc, (MSF *)&play_audio_msf.StartingM);

otoh my ssdh tweak would just lose play_audio_msf implementation, hence its members play_audio_msf.StartingM and play_audio_msf.EndingM,
in that their execution within DeviceIoControl() gets totally commented out:

/*
if (!DeviceIoControl(DrvInfo->drive_handle, IOCTL_CDROM_PLAY_AUDIO_MSF, &play_audio_msf, sizeof(play_audio_msf), NULL, 0, &dwOutByteCount, NULL)) {
		error_code = ProcessError(DrvInfo, TRUE);
		*(WORD *)&VdmReq->header.status = STATUS_ERR(error_code);
		return; 
	}
*/

but start_loc and end_loc are used instead and here's where 150 sectors make their big entrance again:

	FRAMES_TO_MSF(start_loc + 150, &m, &s, &f);
/*
+ 150 !
Compare Glidos CCDAudio::start()
	pparms.dwFrom = frames2msf(m_start);
*/

    	mciPlayParms.dwFrom = MCI_MAKE_MSF(m, s, f);

	FRAMES_TO_MSF(end_loc, &m, &s, &f);
    	mciPlayParms.dwTo = MCI_MAKE_MSF(m, s, f);

 	if (dwReturn = mciSendCommand(wDeviceID, MCI_PLAY, MCI_FROM | MCI_TO | MCI_NOTIFY, (DWORD)(LPVOID) &mciPlayParms))

and so on

comparison here to bear between my

mciSendCommand(wDeviceID, MCI_PLAY, MCI_FROM | MCI_TO | MCI_NOTIFY, (DWORD)(LPVOID) &mciPlayParms)

and Glidos' CCDAudio::start()

::mciSendCommand(m_id, MCI_PLAY, MCI_FROM | MCI_TO, (DWORD) &pparms);

And that's the end of it.
Please forgive me if you can.

[gidierre]

I'm preparing a new, slightly modified version of my TR1 installer for 32/64 bit using Dosbox 0.73 without the cdimage, the coming update of what is here under limited 1.4.2.1 setup
and I was feeling pretty much saddened by the thought that 64bit operating systems, in one word: the future, which is already here, are going to kind of waste all the effort involved in making ssdh.dll (32bit-only compliant) to replace sapucdex

so while I was rebuilding the installer updating v.1.4.x to 1.5 I decided on a whim to try and see if I could effectively insert ssdh.dll or parts of its 16-bit code into the cdaudio tracks playing routines of dosbox, which per se is all 32bit C++ stuff, and I say whim because the dosbox code is perfectly working, so it's a work done just for the fun of it.

I'm writing here for anyone interested, as a segue from previous post about the 150-frame magic number trick, and I'm doing it as long as I myself remember what I've done and why, lest it should fall into oblivion. I'm a fool maybe, but am sincerely confident some day some fellow is going to build on this and make it even better.

At first, I tried to run ssdh.exe and .dll straight within a dosbox session and it failed, with the somewhat mystifying warning: ssdh will run only under Windows NT.
Actually, a quick glance at ssdh.asm, the assembly code behind ssdh.exe (while ssdh.c codes for ssdh.dll) shows this:

sRunUnderNT		db	0Dh,0Ah,'ssdh will run only under Windows NT.',0Dh,0Ah,'$'

Start		PROC NEAR
	mov		ax, 3306h		; DOS 5+ - GET TRUE VERSION NUMBER
	int		21h			; BX = 3205h if Windows NT DOS box (version 5.50)
	.IF		bx != 3205h
	@ShowStr sRunUnderNT, cs
	jmp		exit
	.ENDIF

in other words, what's required is not really WinNT, period. It's a Windows NT v5.50 DOS box which is a must here or it crashes. Check out this.
So what happens here is that if INT21h (DOS 5+ - GET TRUE VERSION NUMBER) for AX=3306h returns BX that's NOT 3205h, as BL (major version) here is not 05h and BH (minor version) is not 32h, that means it's no Dos 5.50 and we're stuck in dosbox default environment, emulating Dos version 5.00, but...
fortunately the dosbox command "ver set 5 50" lets you fake Dos 5.50 just fine so this is easily solved. Now ssdh will install. So sagt die hex

Erm.. it installs, but it all locks up at once . A conflict. What now?
Dosbox has no config.sys (it's no real dos after all) so you can't just put, say a oakcdrom.sys driver in its folder and write as usual something like
DEVICEHIGH=c:\oakcdrom.sys /d:mscd001
and in autoexec.bat respectively
LH mscdex /d:mscd001 /l:d
dosbox won't accept real mode drivers, I tried using in that [autoexec] portion of config file a tool like ctload.exe or drvload.com (see here)
who normally can bypass the config.sys step and launch drivers directly from autoexec, like:
drvload c:\oakcdrom.sys /d:mscd001
they just fail, drive not found.

Last resort, grab dosbox 0.73 source
in which cdrom.cpp
is the file to go to, although if you're really interested cdrom_ioctl_win32.cpp is also worth perusing and how.
It uses SDL libraries to have cdrom access, I "implant" snippets of my ssdh source for play/stop audio, based on MCI stuff (as opposed to SDL) and it finally works.
I have to put some initialization and variable declarations first:

#include <mmsystem.h>
bool success = 0;
int wDeviceID = 0;
MCI_OPEN_PARMS mciOpenParms;
MCI_SET_PARMS mciSetParms;
MCI_PLAY_PARMS mciPlayParms;
#define CD_FPS	75
#define FRAMES_TO_MSF(f, M,S,F)	{				\
	int value = f;							\
	*(F) = value%CD_FPS;						\
	value /= CD_FPS;						\
	*(S) = value%60;						\
	value /= 60;							\
	*(M) = value;							\
}

then work the fairly straightforward pristine PlayAudioSector and StopAudio functions

bool CDROM_Interface_SDL::PlayAudioSector(unsigned long start,unsigned long len) {	
	SDL_CDClose(cd);
	cd = SDL_CDOpen(driveID);
	bool success = (SDL_CDPlay(cd, start+150, len) == 0);
	return success;
}

bool CDROM_Interface_SDL::StopAudio(void) {
	SDL_CDClose(cd);
	cd = SDL_CDOpen(driveID);
	bool success = (SDL_CDStop(cd) == 0);
	return success;
}

so finally they turn into this

bool CDROM_Interface_SDL::PlayAudioSector(unsigned long start,unsigned long len) { 
	// Opens a CD audio device by specifying a device-type constant.
	mciOpenParms.lpstrDeviceType = (LPCSTR) MCI_DEVTYPE_CD_AUDIO;
	if (mciSendCommand(0, MCI_OPEN, MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID|MCI_OPEN_SHAREABLE,(DWORD)(LPVOID) &mciOpenParms))
    		{
        		// Failed to open device. Don't close it; just return error.
			success = 0;
			return success;
    		} 
	// The device opened successfully; get the device ID.
	wDeviceID = mciOpenParms.wDeviceID;
	unsigned long end_loc = 0;
	DWORD dwReturn;
	int m, s, f;
	mciPlayParms.dwFrom = 0L;
    	mciPlayParms.dwTo = 0L;

	// Set the time format to minute/second/frame (MSF).
    	mciSetParms.dwTimeFormat = MCI_FORMAT_MSF;
    	if (dwReturn = mciSendCommand(wDeviceID, MCI_SET, MCI_SET_TIME_FORMAT, (DWORD)(LPVOID) &mciSetParms))
    		{
			success = 0;
			return success;
    		} 

	FRAMES_TO_MSF(start + 150, &m, &s, &f);	// + 150 !
    	mciPlayParms.dwFrom = MCI_MAKE_MSF(m, s, f);
	end_loc = start + len;
	FRAMES_TO_MSF(end_loc, &m, &s, &f);
    	mciPlayParms.dwTo = MCI_MAKE_MSF(m, s, f);

	if (dwReturn = mciSendCommand(wDeviceID, MCI_PLAY, MCI_FROM | MCI_TO | MCI_NOTIFY, (DWORD)(LPVOID) &mciPlayParms))
			{
			FRAMES_TO_MSF(end_loc - 1, &m, &s, &f);
			mciPlayParms.dwTo = MCI_MAKE_MSF(m, s, f); 

				if (dwReturn = mciSendCommand(wDeviceID, MCI_PLAY,
				MCI_FROM | MCI_TO | MCI_NOTIFY, (DWORD)(LPVOID) &mciPlayParms))
				{
						success = 0;
						return success;
				}
				else
						success = 1;
			}
		success = 1;

	return success;
}


bool CDROM_Interface_SDL::StopAudio(void) {
	// Opens a CD audio device by specifying a device-type constant.
	mciOpenParms.lpstrDeviceType = (LPCSTR) MCI_DEVTYPE_CD_AUDIO;
	if (mciSendCommand(0, MCI_OPEN, MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID|MCI_OPEN_SHAREABLE,(DWORD)(LPVOID) &mciOpenParms))
   		{
        		// Failed to open device. Don't close it; just return error.
			success = 0;
			return success;
    		} 
	// The device opened successfully; get the device ID.
	wDeviceID = mciOpenParms.wDeviceID;
	DWORD dwReturn;
	if (dwReturn = mciSendCommand(wDeviceID, MCI_PAUSE, MCI_WAIT, (DWORD)(LPVOID) &mciPlayParms))
		{
			success = 0;
		}
	else
			success = 1;
	return success;
}

notice how in PlayAudioSector I must needs intercept the start (for starting sector number) and len (length of playtime in sectors) parameters, and obviously start + len = ending sector number,
then convert these just as I did with ssdh to MCI_PLAY_PARMS parameters and From/To references for windows to know where/when to start and stop playing the tracks

also notice I pay no heed to Pause, GetAudioTrackInfo and even GetAudioStatus functions, because after my hard earned experience messing with sapucdex/ssdh routines I know they're not worth editing

just the same way, I care to issue the MCI_PAUSE command only there, as opposed e.g. to MCI_STOP, for I'm well aware it's not necessary, not for Tomb Raider 1 at least, to bother with it too, only PAUSE I pick up and the rest I leave alone, it will work anyway.

compiled it with MinGW/Msys free compiler, it's fine.

Note: those who want to try and compile from open gulikoza's glide source using said freeware compiler, be sure to add an #include <math.h> in direct3d.cpp, or else compilation will stop with an error.


In the end, this has really made my day , I've been having a ball doing it
and so, creation of the installers aside, both my coding contributions to the undeclared "Tomb Raider 1 survival beyond WinXP project" are now included in the 1.5 installer that covers all the Vista/7 32/64bit ground:

one for the ear, granting cdaudio track access to post-XP machines, tweaking sapucdex via MCI library now hardcoded in cdrom.cpp (part of dosbox sourcecode)

one for the eye, recreating Lara's shadow that was lost in dosbox/glide, hardcoded in glide.cpp (not in standard dosbox source, but a file from gulikoza's glide patch extension)

Remember, dosbox is THE emulation tool that will grant Tomb Raider 1 for pc a bright prospect down the line when WinXP and 32bit cpu's and OS's are forgotten for good,
and such an ending is already written crystal clear in the future, like every wikipedia reader knows, or is bound to know,
so in an irresistible way [manic laughter] all the world is playing into my hands


EDIT
it's a little bit funny that mixing MCI calls into a SDL framework as I did should have worked.
Frankly, I had no idea this could be such a sensible thing to do, although probably this is just what made me feel like trying
but admittedly sneaking pieces of a different library into functions of a C++ class called CDROM_Interface_SDL is somewhat bizarre.

Looks like unknowingly I was paying a tribute to the perfect chef d'oeuvre of 20th Century art: la condition humaine


P.S.
Please do not lesnerize.

[djklink20009]

im not looking for 10 tracks i want the whole 56 found on the psx version my question is can it be done

[gidierre]

Originally Posted by djklink20009

im not looking for 10 tracks i want the whole 56 found on the psx version

56? aren't they 59?
actually I have never seen a psx tr1 cd, always used pc, but I gather this info from what great KMO wrote in his (already quoted before) Release 1.10/ReadMe1st.html :

the in-game music cues that have always been present in the level files and were heard in the PlayStation version, but have so far been ignored by the PC version
...
The track structure is as follows:
Track 1: Data
Tracks 2–10: Title, ambience and cut-scene audio as on original PC CD
Tracks 11–27: Extra music tracks 3–21 from the PlayStation CD, with some gaps
Track 28: Silence (such as track 57 from the PlayStation CD)
Tracks 29–59: Dialogue tracks 26–56 from the PlayStation CD
Track 60: Secret chimes (track 13 from the PlayStation CD)

Originally Posted by djklink20009

my question is can it be done

yes it can
now you've made me curious about all this psx tracks thing I had so often read about, but could never hear
so I decided to give it a try and following KMO's path:

You can play with sound in the original PC style, original PlayStation style, or in a combined PC/PlayStation style similar to Tomb Raider II, with a couple of variants. It's surprising how much the feel of the game can be changed purely by this choice

I went for the -audio 2 switch

Tomb Raider II style (-audio 2)
This is the style that was adopted for Tomb Raider II and further sequels. It retains the continuous ambience of the PC version, but restores the use of dramatic music at key points. This is the most elegant way to get add the missing PlayStation music without disturbing the normal ambience that PC players are accustomed to.
•Looping ambience as on original PC version.
•Music cues interrupt the ambience, which then resumes.
•Dialogue and secret chimes played from CD if available.
•Four ambience tracks.

atm I'm testing it manually
(that means: get the psx .mp3 tracks, convert to .wav, burn mixed-mode cd, use KMO's patch via my own TR1 dosbox installer version 1.5, but mounting the drives one by one and tweaking it a bit vs. the way I designed it so it can now take command line arguments, such as tomb3dfx.exe -audio 2 as required)
and can already confirm it's good, very nice

I have to thank you for asking this question, otherwise probably I would have never overcome my laziness hence forever missing the experience of playing TR1 with these music cues that somehow remind me of the TR2 and 3 feel

P.S.
if there's some interest/request from you or anyone,
I was thinking I could take the time to automate this psx tracks addon, I mean make a new image out of it, since anytime these "new" tracks butt in, and then the ambience resumes, I can feel a distinct lag obviously from repeated cd access and I guess using a cd image (pc cdrom + psx tracks) with kmo's patched exe should be perfect to fix this

once the image is made and I tested it, I could add it to a refurbished version of what is now my 1.4.2 dosbox installer (the one with image as opposed to 1.5) so as to include the psx music in a fully automated way
what about it?

[gidierre]

after what I said

Originally Posted by gidierre

I could make a new image out of it, since anytime these "new" tracks butt in, and then the ambience resumes, I can feel a distinct lag obviously from repeated cd access and I guess using a cd image (pc cdrom + psx tracks) should be perfect to fix this

I finally made the image (613 MB before compression) and, as it was logical to anticipate, using the image will fully eliminate those annoying (imho) "double hiccups" that occurr at every track onset, half a second slowdown felt twice: once as each psx track (#11 to 26) kicks in and then presently when the ambience resumes,
with image, no hiccup couplets

btw the tombeng.cue of the psx/pc cdrom mix shows for all tracks this pattern:

---
TRACK 57 AUDIO
FLAGS DCP
INDEX 00 60:07:33
INDEX 01 60:09:33
TRACK 58 AUDIO
FLAGS DCP
INDEX 00 60:16:40
INDEX 01 60:18:40
---

etc.
I'm talking about the DCP (Digital copy permitted) flag
interesting isn't it since by default, all tracks on a cd have the subcode flag "Digital copy" not permitted

this simplifies the process, whose steps I'll summarize again:

copy all files from pc cdrom (go it manually, make no .iso or .bin here: no image, OK?) and...good thing no compression/encryption/checksum/protection gimmick is involved here, or else
get the whole psx audio track set (in .mp3 so convert to .wav)
burn mixed-mode cd, careful not to mess with track order & numbering!
now make .bin image
mount in dosbox, using KMO's patched exe with the preconfigured 1.4.2 installer with a minimum of tweaks to make things smoother
it works


EDIT
as shown here:
http://www.tombraiderforums.com/show....php?p=4475003
I've now come to include all the psx audio files into new v1.6 of my dosbox installer.