Leaderboard

History This post was written almost a year and a half before I came along and began expounding on his research. Around October 2, 2011 I started on my hunt for a convertor for .TUN files. I found out that is no such audio file. The file type had actually been known since bartvbl made that post: VOX. The LEGO Racers music is actually VOX audio with a TUN extension. I soon found a command-line program that was able to convert normal (MP3, WAV, such like that) to VOX, namely, Sound eXchange (SoX). I found a piece of music that I liked, and converted it. I sapped it in the game files, and gave it the proper name. I loaded the game, and the music played. But it was really low in volume, and it was really, really slow. I figured out that the file hertz was what made the file slow. I raised it, converted the music, and loaded the game again. This time, it was even slower. I lowered the hertz next, and to my surprise, the music went faster! I finally found the right hertz after a few more tries. During this process, I discovered an interesting... issue, for lack of a better word. The higher the hertz of your custom music, the slower it will play in game.The lower the hertz, the faster the music will play. The real music was produced at 44100 Hz, and it plays at the correct speed in Audacity when imported However, the custom music has to be produced at 22050 Hz to play correctly in-game. Once I figured that out, I started working on the volume. I said earlier that my music was way too low in volume in-game. Combined with the fact that the official music was loud in raw form, I deduced out that the game lowers the volume of the music. I tried amplifying the music in Audacity, but every time I did that, I got an error from the SoX that it was really loud, and that it lowered the volume. When that file was put in-game, the audio volume would be in flux: It would be loud for a second, then low for a while, the loud again. I found out that the convertor lowered the really loud parts, and the lower parts that were not too loud, it left alone. I tried to amplify the music using the tools built into SoX, but that did not work. Amplifying in both Audacity and SoX did not work either. The result was the same: the music volume was in flux. rioforce (my brother) had been watching me every now and then, and of course I told him what was going on and what was happening.. He said he might know what was going on. The raw files, are very load when imported but, the waveforms are all the same: flat on top and bottom. rioforce suggested this: Amplify the music, normalize it, then export the file and convert it. I did that, and the results were better than what I was doing before. SoX did not give me an error, and the music was not in flux in-game. I figured out a SoX command so the amplified music would not be clipped when being converted. Using that command, I got good results too, though not as good as amplifying then normalizing. In addition, with the command, the converted music was not distorted in-game, unlike the other method. In the end, I chose to use the command over the amplifying and normalizing. After being amplified and normalized, some of the music I choose was back to its original volume, and completely wiped out my changes. Fast-forward to the third week of February 2012. I had found out the month before that Audacity could export VOX files in addition to importing them, but it was very flaky. Sometimes it worked, sometimes it didn't. I had decided to wait for the next release of Audacity to update this tutorial to use only Audacity. But Audacity updates were spread far out, and I didn't really want to wait for the next one. So I started messing with VOX exports again, and I got it to export every time, even though I got a phony error message most of the time. I tested my files, and they did worked in LEGO Racers, a bit better than using SoX, but not perfectly. I proceeded to update this tutorial with the new info and method. On April 29, 2013, rioforce began looking at creating working custom music for Racers. He actually had been developing a method for a few months, and had actually uploaded a video showing off his WIP method. But on the 29th, he really began finalizing that method. Once he had the proper settings, he recorded a video showing how to do it, and wrote up a new tutorial on LEGO Racers Audio Modding, releasing it all on April 30, 2013. The next day, May 1st, I updated the tutorial here, ushering in a new and very nosy wave of LEGO Racers modding. Directions Note: the following tutorial was written in the voice of rioforce. Anytime "I" or a similar reference is used, he is referring to himself. Videos

So here it goes. I was doing all my daily reading of HEX and things, bit of testing here... bit of testing there. I was looking at the file listing of DR and I noticed a file named "DEVELOPER.CFG". I thought. Back I went looking at the GTC to try and make out what the file contained. I made out that it was an INI file and that the first key was probably "[CORE INIT]". I also saw the word "DEBUG". So I made a CFG file in the same path as the original is in the GTC in hopes it may override it. I put in the info hoping that it might result in at least an error with some useful info. So started the game, nothing changed which wasn't really a suprise. So I quit the game and went back to the CFG I wrote. Then a miracle happened.... The game overwrote my invalid ini entries with the full set of default entries. So now I have the full uncompressed Developer.cfg file. I tried changing some entries, but the game keeps writing them back to the default values. Then I tried something else. It had a "DevelopersName" variable. I put in "Henry" just for kicks.... started the game... nothing happened then I quit. The game again wrote to the file... but instead it wrote a CFG setup for a "Steve" which had all different values in it. Now, "Steve" is one of the programmers for the game. Sample: (Yes I tried turning the debug ones on) [cCore, INIT, SINT32] (0 .. 5) TrackVariation = 1 [cCore, INIT, STRING] (24) DeveloperName = "Default" [cCore, INIT, STRING] (100) MapName = "" [cCore, INIT, STRING] (100) Language = "British" [cCore, INIT, STRING] (100) StartupScript = "empty" [cCore, DEBUG, SINT32] (0 .. 1) AllowAllDebug = 1 [cCore, DEBUG, SINT32] (0 .. 1) cSanitaryTextDebug = 0 [cCore, DEBUG, SINT32] (0 .. 1) cConsoleDebugCom = 0 [cCore, DEBUG, SINT32] (0 .. 1) cControllerDebug = 0 [cCore, DEBUG, SINT32] (0 .. 1) cConfigDebug = 0 [cCore, DEBUG, SINT32] (0 .. 1) cVMDebug = 0 [cCore, DEBUG, SINT32] (0 .. 1) KarmaDebug = 0 [cCore, RENDER, SINT32] (0 .. 1) rRenderGemSpline = 0 [cCore, RENDER, SINT32] (0 .. 1) VisRender = 1 [cCore, CONTROLCAR, STRING] (24) ControlCar = "car 0" [cCore, DEFGROUP, SINT32] (0 .. 64) DefaultGroup = 18 Here are the 2 complete CFG's: https://www.rockraidersunited.com/files/dl-r430/ What does this mean? - I have now confirmed where the decompressed file size is located (this applies to LR2 also) - Now knowing the compressed and decompressed state of a file, this should make finding out what the compression is much easier. This effects LEGO Racers also provided they use the exact same compression. - We got a sample of a developers configuration setup. And yes, I checked LR2 to see if it also had a CFG, but it doesn't.

Same as the LEGO Racers 2 INF Tool in that it opens FILELIST & COMPRESS.INF files and exports to tab delimitered text files, except customized to work with the Drome Racers INF files. Download

@Modded Lego I'm looking for a 1999 copy too. The same night I was talking with rio about the no-JAM method, we talked about the trophies too. He also has an idea as to why it may have been removed from the 2001 version. I don't have an analogy to compare it to. Sorry. Rio thinks that the trophies were put into the game because the devs liked the idea. But the devs of the 2001 version didn't like it, so they removed it. But that still leaves us with the question of why they didn't like it. I'm thinking that it may have been a beta item that was not removed by the launch date. So when the 2001 version was being built, they remembered that and removed it from the game.

I can now 100% confirm that ('DataB' when using the inf tool) the second "uint32 {4}" is the decompressed file size and 'DataB' of COMPRESS.INF is the compressed file size. Also I believe the compression is some form of RLE compression.

Ah, ok. Well, it still sounds like a typical ending scenario to me. I guess they decided dinosaurs wrecking the park is more interesting.

No. Think before you post polls like this. Locked.

@JMMB *facepalm* I've seen that topic so many times, yet when I ask about it, I don't think about it. As for the audio, I also mentioned this on the archive format page. @Modded Lego No. There is no way to do that. If there was, we would know about it already.

The save file is a complex thing. It has mystery progress variables and also contains your cars. What would be cool is some way to transplant car data from modded adventure cars like RR's into your save file as a regular custom car to ulock them all, but I have no idea how to do that. The GAMEDATA.GTC is more complex and compressed by unknown methods, preventing us from making an extractor (but other than that, I've figured out the file format). (If anyone wants to give it a wack, I'm pretty sure the first file listed in FILELIST.INF of Drome is that first chunk of binary data in the Drome GAMEDATA.GTC and that file is a text file.)

As far as I know, there is no way to edit the save game expect with a hex editor. But the save file contains so little data that it would be really hard to mod it. The only way we can edit gamedata.gtc is via filelist.inf with an hex editor. And the only thing we can do is move pointers within filelist.inf to other items withing the .gtc (swapping textures, cars, and such). Until we get a extractor, we won't be able to mod any other way.