View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001285 | FSSCP | sound | public | 2007-02-17 03:31 | 2007-03-23 01:38 |
| Reporter | CP5670 | Assigned To | taylor | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.10 | ||||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001285: Music.tbl data is ignored | ||||
| Description | The game ignores the music.tbl parameters and seems to keep playing the files until the end, which prevents the music pieces from lining up correctly and makes some of them sound pretty messed up. This bug is not in 3.6.9, but appears in the January 24 "XT" build and possibly in recent CVS builds as well. Just a guess: it may have something to do with the automatic searching for ogg and wav files that was added since then. However, I don't have any instances of multiple versions of the same files. The game is running off the same files (wavs) that are specified in music.tbl. | ||||
| Tags | No tags attached. | ||||
|
|
The samples-per-measure is now automatically generated, possibly incorrectly. Can you post a test audio file, plus it's full music.tbl entry, so that I can see what's going on? The auto-gen stuff wasn't getting it 100% correct, but was generally close. You just had to get the number of measures correct. It's possible that there is something else wrong with the code though, so it's safe to blame this on me until a different cause can be found. |
|
|
Note that many music files aren't actually played all the way to the end. The number of measures setting is supposed control the truncation point. I think the best example of this problem is the track B enemy arrival piece, FS2_Arv_B04.wav, which has the following parameters: $Name: FS2_Arv_B04.wav 4.8 75600 For reference, this is a 22khz file at 706kbit/sec. You'll notice that it sounds fairly different in 3.6.9 and the 1/24 build, where it's played up until the end of the file. I can upload a test mission to play around with this stuff if you need it. |
|
|
The autodetection is calculating the SPM for that file at 139517. And according to the math, that's correct. It's 88kb/s * 15sec = 137.5ks/m (not as accurate the code gets obviously). This is the issue that I have with the entries in music.tbl, they are completely arbitrary and appear to have no basis in mathematical reality. The it's still doing what it's supposed to, and truncating like usual, but the truncation point is different when you don't use an arbitrary value. If you can figure out how they got 75600 for that piece of audio, then I'd be happy to know what it is. |
|
|
I think I've managed to crack this. The samples per measure is given by SPM = (2*SF*L)/NM, where SF is the sampling frequency in hz, L is the length of the piece in seconds (only the amount that should be played), and NM is the number of measures. This gave correct results on all the files I checked out. Of course, the presence of L means that you can't determine the SPM automatically. I think the best way to proceed with this is to have the game read the SPM values in music.tbl, and if a wav file is specified in there, assume that the given SPM is for a 22050hz file (which is the case for all retail music). If the game encounters an ogg with the same name, which will almost certainly be 44100hz, then multiply the SPM by 2 to get the new value. If an ogg is specified in music.tbl, you can do the same thing but in reverse; divide by 2 if the game finds a wav. Also, taking this into account, I'm not sure what the relevance of NM is to the game. It seems that you can put it an arbitrary value for that, as long as the SPM matches up with it. I have put some custom music into the game before without ever really understanding how the NM worked, and maybe this is why I was able to get it working. |
|
|
Unfortunately that assumes too much for us to actually manage it automatically. It's just too error prone. I would sooner remove the any-extension support than try to deal with that crap. Can you think of anything else that would allow us to autogen this value? If not then there is really no choice but to revert the code in question and have music.tbl force specific file types. Oh, and NM is multiplied by SPM to determine the byte-cutoff for the audio code. That's how the game uses it anyway. Perhaps taking that into account can help figure out how best to fix this so that autogen will work properly (ie, using NM to determine the proper byte-cutoff rather than figuring out SPM). |
|
|
Is that all the NM is used for? Since that would confirm what I suspected earlier: the NM doesn't actually affect the game at all, provided that the SPM is computed correctly. The critical piece of information is L, which is in a sense "encoded" in the SPM value. I think you'll have to use the SPM values in the table one way or another. In order to "recover" L from the SPM, you need both NM and SF. NM is given, but SF is the sampling frequency of the file that the music.tbl entry was designed for, not necessarily the frequency of the music piece that the game finds. I can't see any way of getting around this, short of manually computing all the L values and rewriting the entire music.tbl. |
|
|
How is the L value derived in the first place? I can only assume that there is an actual formula, or base value, that it's calculated with. If not then it's totally arbitrary, and that doesn't do any good for anyone, especially the person that came up with the values originally. If it's a purely musical thing, then we don't even need to try to figure it out, and just accept a value as specific to that file only. The problem with using the same SPM is that we have to assume that the audio is actually the same, just in another format. If it's longer or shorter, or even a completely different track, then the value is useless. I really don't want to get into a whole thing where we dictate how that all works. That was the point of having it automatically generated in the first place, so that you will actually know what you are going to get when you stick a new piece of music in the game. If we can't arrive at a forumla which can reliably produce acceptable results then we are just guessing, and that doesn't help anybody, so the code will simply have to be ripped out and put back the way that it was before. |
|
|
You can't really derive L. It's simply based on where the music transition sounds good. :p For example, in the FS2_Arv_B04 file, the specified L is about 8, even though the file is 15 seconds long. In some cases, L may be a second or two less than the full length of the file, while in other cases it may only goes halfway through the music piece. If the thing I described earlier is too complicated to use, you'll have to go back to the old system for ingame music. The code will still be useful for briefing tracks, voices and the play-sound-from-file sexp though. |
|
|
Crap. That's pretty stupid if you ask me. :p But, I guess there just isn't anything that we can do about it. We have to go back to the old loading method for everything though, it's the same code. Music, briefing voices, and the sexps are all hanlded the same way, it's just that music has the extra tbl entries. The best that I could do is have it honor any extension that exists, but if one doesn't exist then it will just find the first available file matching the base name. Doing that should let me fix the extra period problem at the same time. |
|
|
Ok, I think that I've found enough of a compromise to get it all working properly. All of the soundtrack filenames in music.tbl will honor the extension if one exists. Everything else (menu music, (de)briefing voices, sexp stuff) will have it's extension removed, if one exists, so that it can find either an OGG or WAV version. |
|
|
Sounds good. If you have a test build with the fix, send it to me and I'll make sure that everything is working correctly. |
|
|
I /think/ I've got this working well now, but double-check and let me know: http://icculus.org/~taylor/fso/willrobinson/Xt0227-win32.rar |
|
|
I tried several things with this and everything seems to be working as it should. :) |
|
|
Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-02-17 03:31 | CP5670 | New Issue | |
| 2007-02-17 05:49 | taylor | Note Added: 0007644 | |
| 2007-02-17 05:49 | taylor | Status | new => assigned |
| 2007-02-17 05:49 | taylor | Assigned To | => taylor |
| 2007-02-17 12:24 | CP5670 | Note Added: 0007647 | |
| 2007-02-18 00:52 | taylor | Note Added: 0007656 | |
| 2007-02-18 03:24 | CP5670 | Note Added: 0007657 | |
| 2007-02-18 04:59 | taylor | Note Added: 0007658 | |
| 2007-02-18 05:00 | taylor | Note Edited: 0007658 | |
| 2007-02-18 06:12 | CP5670 | Note Added: 0007659 | |
| 2007-02-18 10:46 | taylor | Note Added: 0007660 | |
| 2007-02-18 12:10 | CP5670 | Note Added: 0007661 | |
| 2007-02-18 13:09 | taylor | Note Added: 0007662 | |
| 2007-02-19 01:48 | taylor | Note Added: 0007668 | |
| 2007-02-19 04:55 | CP5670 | Note Added: 0007669 | |
| 2007-02-27 10:50 | taylor | Note Added: 0007741 | |
| 2007-02-28 14:55 | CP5670 | Note Added: 0007766 | |
| 2007-03-23 01:38 | taylor | Status | assigned => resolved |
| 2007-03-23 01:38 | taylor | Fixed in Version | => 3.6.10 |
| 2007-03-23 01:38 | taylor | Resolution | open => fixed |
| 2007-03-23 01:38 | taylor | Note Added: 0007876 |
