MP3 Support

[Baker]

[revelator]

[mh]

[Spirit]

[mh]

[Spike]

[Baker]

[Baker]

Random thoughts related to the discussion:

1. I'd like to see the music indicated in worldspawn be like "mysong" instead of a silly number. I think it would be cool for modders to be able to explicitly name the song playing instead of some number. Even worse that this number needs x-1, which is confusing.

2. I haven't looked at the protocol to see if #1 interferes with it or is even indicated (aside from the DP_ extension), but I know any half-way serious player isn't going to use a cd track in multiplayer because it interferes with hearing and consumes resources. But coop maybe.

Case in point, with Travail ( I made that works with the Fitz 0.85 in post #1), why should the names of the sounds be renamed from, say, "In Memoria" or what not to the bland "track03.mp3".

It's like doing the scrubs all the humanity out of authorship of music. Much better for a map author to put "memoria" in worldspawn and have it play that mp3. I mean, if you are going to rethink whether a standard is good, rethink it all.

(No idea what would happen to an existing engine if it encountered a non-numeric "cd track" name. Maybe use different worldspawn "name" like "music".)

[mh]

Good points. I addressed this in DirectQ by allowing the MP3s to retain their original names and instead using the number as an index in the file listing, but your idea of being able to specify a name in worldspawn is something I never really thought of. In theory it could be OK, as the worldspawn key can be read and reacted to separately at load time. In practice the messy part is that the Quake architecture specifies a CD tracknumber which is only accessed by the server and sent to the client as an svc_cdtrack message. This would also mean that the server (including QC) would have the ability to specify an arbitrary change of CD track at any point during gameplay.

Now, the interesting thing is that the Red Book spec only allows up to 99 tracks on a CD, and the message is sent as a byte. It's hacky, but given that this is a clear case where a certain type of message that would otherwise never be used exists, one could interpret a value above 100 as indicating that the message is to be followed by a string; possibly just a track name but more usefully a command that could play, pause, stop, change volume, etc.

I wouldn't be comfortable implementing this without a protocol or QC extension, but that's where we're getting into other territories (and where my proposed extensible protocol would be a Good Thing, rather than having to invent complete new protocols for every additional thing, no matter how minor).

[mh]

[Spike]

[Baker]

[mh]

[Baker]

[Spike]