creating iMuse effect in AGS?

[Gilbert]

It's too terrible to have a bunch of uncompressed Wave files lying around in a game's folder.
IMO 10MB is large enough for a very large game already, 600MB...

[Janik]

Well, to me 600 MB doesn't seem like that much, but my latest drive has 200 GB

I am thinking of an alternative method that might work if the MP3/OGG always plays at the correct rate. For example:

----
PlayMusic( some MP3 file # here)

StartPreciseTimer //A plugin could do that - precise timing to better than ms precision. AGS' GetTime function is only precise to seconds.

//Somewhere in RepEx:
If (PreciseTimer >= some position) PlayMusic( the other music file #)
----

A significant caveat there is that if the player switches (Alt-Tab) out of the game, the music is paused, so your timing would be way off. But perhaps then GetMP3PosMillis() could be used to check the other timer's validity?

[modgeulator]

Hmmm... an intersesting idea, but I don't think the music and timer would start at exactly the same time. And, even if you could get a timer to trigger the change at the exact right millisecond I think there are issues with the very nature of compressed audio playback that would still cause it to glitch badly.
I think to get a system like this working with compressed audio would require some clever pre-caching trickery...

[Janik]

And there's an even bigger issue if using scripting to start the other track - with a game speed of 40 fps, that's 25 ms per frame, so that limits the accuracy of starting a track to +- 12 ms or so; and it wouldn't matter if it's a WAV or MP3.

This (again) points towards using a plugin instead. But perhaps it could play digital sound instead of using directmusic producer?

[fovmester]

PreloadChunk(int milliseconds, BlockingStyle blocking)

That sounds a bit too low-level for a script language.

[modgeulator]

Here's a quick little demo I put together using .wavs to show how I envision this working...

http://iinet.net.au/~snderson/musictest.exe

(self-extracting rar, please make sure to extract this to a new folder)

[Nikolas]

In my computer (Athlon 1800 2800Mhz), it takes some time from track to track.

On the matter of quality for the composer:

When you compress a music file from WAV to MP3 cor OGG, you kinda fuck with the waveform. So uncompressing it will create a bad quality for the music. MP3s are good only for transfering purposes. If you turn an MP3 back to WAV (or AIF), you get poor results. Just my little thought, since I'm a composer.

[Elliott Hird]

600mb just makes your game look cool . PM me modgeu-thingymabob, I think I can be of help.

[modgeulator]

In my computer (Athlon 1800 2800Mhz), it takes some time from track to track.

In what way does it take time? It's meant to wait until the end of the measure before changing if that's what you mean. Or do you mean that it pauses and the sound breaks up?

BTW, it's impractical to distribute with uncompressed WAV files - I convert from OGG back to WAV not for sound quality but so the position in the file can be tracked accurately during playback (as was discussed extensively in this thread already.)

[Adamski]

I agree with Gilbot, there's no way I'm going to distribute a freeware game that uncompresses to 600mb, especially if the music's been lossy-compressed.

Also Nikolas, I think your explination of lossy-compressed music is a bit... lacking Obviously uncompressing an OGG or MP3 will not put back in the data it chopped out when compressing, but it won't necessarily be 'bad quality'... unless you compressed at 64kbp/s or something silly.

Anyway, I think the point is to not get worked up over this niggling issue to the point of surprising people with games that uncompress to half a gig. You can still do crossfading and lots of cool little iMuse things without needing to syncronise two tracks.

[Janik]

Your tech demo was pretty impressive - I found that turning the sax solo on/off worked fine, and the "transition to variation" too. However, with the "transition back" button, there was a little silent pause before the first tune started up again.

I wonder, would your method still work if only the short transitions were WAVs, with the longer tunes kept compressed?

[modgeulator]

Thanks. The pause before the tune kicks back in was deliberate, it was intended to sound like that. If it sounds a bit wonky it's because I put it together quickly just to see if it would work more than a problem with the system itself. Thanks for the feedback, btw what speed computer were you using? I'm working with an Athlon 2800 and haven't tested it on anything slower.

I wonder, would your method still work if only the short transitions were WAVs, with the longer tunes kept compressed?

No, you need to be able to track the position in the song you want to transition from accurately - it possibly would work the other way around (only compressing the transitions), but that wouldn't help very much with the size problem.

[Janik]

I tried it at work with a P4, 2 GHz, and at home with my Athlon 64 3500+; it worked the same on both computers, as far as I could tell.

[Nikolas]

In what way does it take time? It's meant to wait until the end of the measure before changing if that's what you mean. Or do you mean that it pauses and the sound breaks up?

BTW, it's impractical to distribute with uncompressed WAV files - I convert from OGG back to WAV not for sound quality but so the position in the file can be tracked accurately during playback (as was discussed extensively in this thread already.)

There is a slight loss of rhythm. When I press the sax button there is a very slight delay and with the transition button it is the same.

I know why you had to uncompress the music files.

I'd love to have this options as a composer, don't get me wrong. One problem I have, as mentioned before I think, is that it's strange to have a game of 10-20 Mb and the music be 600!

@Adamaski: I checked it a bit further. I believe that there is actuall further loss when you decompress. At least this is what I hear and this is what I see in the waveforms. I checked the original WAV file, the MP3 at 128 Kbps and the MP3 back to WAV. Everything done to Cubase at the highest quality (and slowest). The WAV files have 1411 Kbps, thus enhancing the "wrongs" of the MP3. You can see that there are differences in the waveform. I don't think that it's alot but anyway, just my thoughts (which are a bit off-topic). It's just that I would love to make proper music files for games but webspaces does not permits us to do that...

[modgeulator]

There is a slight loss of rhythm. When I press the sax button there is a very slight delay and with the transition button it is the same.

Yeah, for some reason when you use SeekMP3Position() on a wave file it seeks to a sample (I think) instead of to a millisecond - so I had some difficulty compensating for that.

@Adamaski: I checked it a bit further. I believe that there is actuall further loss when you decompress. At least this is what I hear and this is what I see in the waveforms. I checked the original WAV file, the MP3 at 128 Kbps and the MP3 back to WAV. Everything done to Cubase at the highest quality (and slowest). The WAV files have 1411 Kbps, thus enhancing the "wrongs" of the MP3. You can see that there are differences in the waveform. I don't think that it's alot but anyway, just my thoughts (which are a bit off-topic).

But when you playback audio you're decompressing it, it sounds like there was something iffy in the algorythms used in one of the programs you tried with.

[Nikolas]

I had an idea. I don't know nothing about AGS and how to do it, but I was thinking this:

If you had a track at lets say 120 bmp and you wanted to smoothly take it to other places without breaking the track at all, right? You could keep this track in MP3 format and have another "empty" track in WAv form. The second WAV form could be only one bar. This way you wouldn't need to track the MP3 or make it into WAV, thus wasting space and quality (according to me, which is not the issue here), but you could track the WAV file which would be noiseless and only 1 bar. This could give you the exact place of where you're playing. And if you could loop this 1 bar you could see if it has been looped 4-6-8-16 times and thus keep your melody into place.

Could this work?

[modgeulator]

Yeah, I was wondering about something like that. The first problem is that you can only play one music track at a time. Second problem is that there would be a varying delay introduced everytime you try to play two sounds at the same time that would only make matters worse.

Anyway, I had another little play around with MIDI files and I found that you can transition smoothly from one to another, but you have to edit the MIDI so that everything is offset by about a 32nd beat, so that nothing from the next measure is played when you change MIDIs. I'm thinking of putting together a simple little module for this, if anyone is still interested in working with MIDI.

[Nikolas]

Yeah, I was wondering about something like that. The first problem is that you can only play one music track at a time.

About the first problem I believe that you can have more than one audio files playing at the same time. Like if you have fx along with music. I think it has something to do with different channels or something. Sorry for not being able to be more helpful. I find very interesting what you're trying to do...

[Elliott Hird]

PlaySound(int sound, int channel) just name the blank one soundx.wav

[Campusanis]

The music is decoded in chunks and if you seek to a specific position then the decoder seems to need to decode the whole chunk that you're in, which leads to the effect that you describe.

I'm not sure if it'll make any sense, but could we know how long these chunks are (or don't they have a constant length)? I would try to make the game wait until the MP3/Ogg/whatsoever is at the end of such a chunk and then start the transition, so there wouldn't be any delays then.
I noticed that sometimes the transition is accurate and sometimes it isn't. So I concluded that the delay depends on where you currently are in one "chunk" (lovely word). Early means big delay, the nearer to the end, the smaller is the delay. Did I misinterpret this?