[Mant]

Both versions of Fred2 posted crash if you try to do duplicate model texture replacement.

[WMCoolmon]

DaBrain: I suspect it is, unless this only happens if you run the build in the H-Q sound thread, and the first one in this thread.

Originally posted by Moonsword
Query:
Are the modular .tbl files in this build?

Yes

Originally posted by Man
Both versions of Fred2 posted crash if you try to do dubpicate model texture replacement.

Do you have any error info, and is the bug not in mantis? RT is working on patching up Fred2 at the moment, I don't know if I'll be much help unless it's something simple.

[Mant]

All I get is Window's "Fred2_open 3.5.5 has encountered a problem and needs to close" window, no details.

Older Fred2s I have work just fine, even OGL ones. I haven't put anything in Mantis, I thought that was just for "offical" builds? I can if it will help.

[WMCoolmon]

This is basically the 3.6 EXE with a few extra SEXPs and the fixes for it to work with modular tables. Nothing to do with the texture replacement system.

Do you have any older 3.6-or-later FRED exes that work?

[Goober5000]

Originally posted by Mant
Both versions of Fred2 posted crash if you try to do duplicate model texture replacement.

When is the crash?  As soon as you select the texture, or not until you save the mission?

If it's the latter, can you still load the mission in FRED after the crash?

[Nix]

Not to derail the current discussion, but what exactly is the new sound samplerate settings supposed to do?  Are they supposed to lift the limits of the 8B22k and 16B11K sounds so far?

I honestly dont know if it matters what format the sound is in, because in V's original files, there are 16B11K files in the 8B22K directory in the main VP.  Plus the bitrates range between 8 bit and 16 bit in that directory too.  I wonder if this has something to do with DirectX?

Perhaps, inserting our own high quality SFX files at 16 bits, 44K would not matter to the engine, and could be played back without problems?  That is if anyone wanted to do that in a future mod or something.

[WMCoolmon]

That's how it seems ATM.

[Mant]

Originally posted by Goober5000
When is the crash?  As soon as you select the texture, or not until you save the mission?

If it's the latter, can you still load the mission in FRED after the crash?

I select the texture, then is takes me back to the ship menu. When a close that down it crashes within a few seconds. I don't get time to save.

I have a version that works, but it is just called fred2_open_r, all I can tell you about which version it is it that it is OGL and I downloaded it 9th May, sorry.

Worse though, it turns out Freespce 3.6 does a CTD the moment a ship with duplicate model texture replacement turns up, and ignores regular texture replacement . I was using duplicate as I never had a build in which regular worked. I've tried some later builds (such as Bobboau 6-10-04) and get the same error.

If someone could look at these I'f really appricate it. I've got a 30 mission campaign using SCP stuff just about ready to release, but it uses a lot of texture replacement and half the missions don't work on recent builds.

I've put both of these into Mantis. If I can help with any testing or anything please let me know.

[Flaser]

OK. That's it.

I'm not expert in digital media storage, or encoding, but there's a point where I feel it's necessary to clear some things up. (My father graduated from this stuff, so he took the liberty to explain a thing or two...)

The KHz that's displayed in Winamp or the properties in the PCM file have nothing to do with the pitch of the sound you hear in the file itself.

It's a sampling rate!

When you take an analog signal, and try to digitalise it, you have to sample if at equal intervals to be able to replicate it.

Basicly the more often you do this, the better the authenticity - (HIFI implies High-Fidelty) - CDs use 44 Khz, DVD-s 48 Khz. Once again this is a sampling rate, this has nothing to do with the properties of the sound!

Freespace used 22 Khz, 'casuse it the smaller sampling rate wasn't as much of a dowgrade. (However it IS noticable! Listen with a good headphone and you'll pick up on it!)

Now we have some samples of the audion we want to store digitally. Now comes the actual digitalisation. The question is the following: how many bits per sample?

CD-s use 16 bits.
This may seem little - the main reason for fake/superstitious audiphiles to whine about the murdering of the good 'ol 100 % authentic vynil dics - in fact, it's is so precise that the recording equipment can't keep the pace with the precision it provides.

You can use less bits and end up with a smaller file.

This is uncompressed, CBR - which means Constant Bit Rate - encoding. Simply put regardless the complexity of the sample I always use the preset ammount of bits for it.

I'll take a small detour here - why do CDs nowadays sound crap? 2 reasons:
1 - they are mixed to be aired. Ergo the volume should be hitting the bottom all the time, this kills the dynamics of the music.
2 - the equipment most people use to listen to their music is far from perfect, moreover - especially when dealing with classical music - some elemets of the music have to be removed to prevent the destruction/damage of your equipment.

Okey, that's an Audio CD a basic digital audio format. What about the rest?

Well now comes the fun part. - All that data is uncompressed. Moreoever a CD also has a lot of redundant data for recovery algorythms to ensure the CDs is playable even when it takes a couple of scratches.

When putting it to hard-drive we can get rid a lot of that redundant stuff.
OK, done it. What's next?

Compress baby! Even Lossless compression methods can free a lot of space.

Now what? Well the opinions differ here:

Use VBR (Variable Bit Rate) encoding/recoding. VBR encoding doesn't always assign the same ammount of bits for each sample, but a varying ammount. - Welcome to MPEG-I layer 3 or in orther words: MP3

Get rid of stuff the human ear can't pick up - don't store too high or too low frequencies, also don't store too quiet stuff for each given frequency. - This is the source of the greatest debates.

Now what does this whole crap mean for the FS_Open?

A file that was sampled at 22 KHz - CAN'T be improoved to sound like one sampled at 44 KHz!
Moreover even though if the engine can play a 44Khz file, it will play a 22Khz as if every second sample was the same as the previous one - listening to a 22KHz stuff won't show any improovement.

The bitrate is a second filter that affect quality, but the same applies here too as with the sampling rates. Raising the limit won't improove existing files.

What good is this stuff then?
Listen to your CD - now listen to an MW radio.
That's the jump the campaign makers can make with the new limits.

What is this Ogg suff?

The same as mp3, except it's free. (Unlike whatever is widely believed mp3 is not free - well building software that uses it is Not).

Nix - get you speakers checked, or get a better one. There is always a very notable difference between files of that quality.

[mrduckman]

You're right, of course.
In any case, moving from ADPCM to OGG or whatever else will be an improvement. ADPCM is old and stinks.

And there's no point to re-do the existing sound files. You may convert them, yes, but not resample them.
If you want it done right, you should record every sound again from the source.

[WMCoolmon]

I made an attempt at resampling the original FS1 m4 track a bit ago. The results were actually, IMHO, pretty good. I also phase shifted the tracks a bit.

If we decide to implement new file format support for the sound system, I stumbled upon this library which I think would satisfy modders, at least for a bit.

Note that as of now, I don't really know what the two registry values do. They change the quality of the Primary buffer (Which is stereo) and the secondary buffer, which is used for EAX. However, setting the sampling rate or number of bits per sample to 0 doesn't seem to do anything.


Bug
It seems that something is escaping the list of used weapons that are loaded. Not sure where it is, though, but I've run into it in a couple of Derelict missions, and the second time it was a Harpoon that caused it...I suspect it might be because a Loki is using the default config.
This will probably be fixed in the next build (Or at least a command line option to revert to loading all weapons)

[mrduckman]

Sound quite good. I heae a little backgroung noise, though.
But well, this is an AWE64 in this linux box.

FYI:

Playing m4_nrml1.wav.
Audio file detected.
==========================================================================
Opening audio decoder: [msadpcm] MS ADPCM audio decoder
AUDIO: 22050 Hz, 1 ch, 16 bit (0x10), ratio: 11155->44100 (89.2 kbit)
Selected audio codec: [msadpcm] afm:msadpcm (MS ADPCM)
==========================================================================
Checking audio filter chain for 22050Hz/1ch/16bit -> 22050Hz/2ch/16bit...
AF_pre: af format: 2 bps, 1 ch, 22050 hz, little endian signed int
AF_pre: 22050Hz 1ch Signed 16-bit (Little-Endian)
AO: [oss] 22050Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 22050Hz/1ch/16bit -> 22050Hz/2ch/16bit...
Video: no video
Starting playback...
A:      1:08.1  0.3% 0%  


Playing m4_nrml1.ogg.
OGG file format detected.
==========================================================================
Opening audio decoder: [libvorbis] Ogg/Vorbis audio decoder
AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 16000->192000 (128.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==========================================================================
Checking audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int
AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 48000Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...
A:      1:08.1  5.3% 0%

[DaBrain]

I can't hear any background noise.

It sounds better than the orginal waw.

I don't unsterstand why though.

It just  shouldn't be that easy

[Lightspeed]

Oy yes, that sure is clearer.

However, you seem to have messed up some of the low frequences i some of the tracks (screechy screech). Also, get rid of the phase shift (or make it smaller) as it is it is kinda annoying.

[Flaser]

Well...maybe FS1 files were so low quality (22KHz - 4 bit! - mono), that even an interpolated resampling (using some kind of algorythm to guess the "lost" data) could end up with better quality...now if we could grab the original HQ source...(I know keep on dreamin....still I doubt :V: or :I: has any use of it).

[mrduckman]

Originally posted by Lightspeed
Oy yes, that sure is clearer.

However, you seem to have messed up some of the low frequences i some of the tracks (screechy screech). Also, get rid of the phase shift (or make it smaller) as it is it is kinda annoying.

Heh. now you know how well I can hear. Even with a whole of noises coming from the datacenter just aside me

[Nix]

Originally posted by Flaser

Freespace used 22 Khz, 'casuse it the smaller sampling rate wasn't as much of a dowgrade. (However it IS noticable! Listen with a good headphone and you'll pick up on it!)

Correct, Actually Freespace 1 used a lower bitrate than Freespace 2, I believe FS2 used 16 Bit audio for music files, whereas Freespace 1 used 4 bit audio files.  I can hear a WORLD of difference between the two files quality-wise.  

Originally posted by Flaser

Compress baby! Even Lossless compression methods can free a lot of space.

Now what? Well the opinions differ here:

Use VBR (Variable Bit Rate) encoding/recoding. VBR encoding doesn't always assign the same ammount of bits for each sample, but a varying ammount. - Welcome to MPEG-I layer 3 or in orther words: MP3

Get rid of stuff the human ear can't pick up - don't store too high or too low frequencies, also don't store too quiet stuff for each given frequency. - This is the source of the greatest debates.

I Like this idea, if FS's sound subsystem can play compressed ADPCM formats, that'd be an easy way to have compressed audio.  OGG would be the best solution, but that would require extra code to be written for FS2Open, which I dont know how to do.

Originally posted by Flaser
A file that was sampled at 22 KHz - CAN'T be improoved to sound like one sampled at 44 KHz!
Moreover even though if the engine can play a 44Khz file, it will play a 22Khz as if every second sample was the same as the previous one - listening to a 22KHz stuff won't show any improovement.

The bitrate is a second filter that affect quality, but the same applies here too as with the sampling rates. Raising the limit won't improove existing files.

I was stressing that the source audio must be in a higher quality format in order for it to sound better.  I know that you can not make a 22K file sound as good as a 44K file.  It's just not possible.  You CAN remix the audio to that higher sample rate and bitrate using Sound Forge, but the result probably wont sound better.  It sounds DIFFERENT than your original 22K source, but sometimes in a worse way.  

My recent test was to take a source file recorded at 44K, 16 bit, and insert it into a mod for FS2Open, then change the settings in the registry to see if the engine would play the file AT ALL.  It did, regardless of the registry setting.  What I was concerned with, was if the sound subsystem actually played files ABOVE 22K, meaning if a file had the properties of my newly inserted file, the sound subsystem would ignore the file and play the original, or not play the sound at all, due to it's properties not matching the engine's capabilies.  Ovbiously, the engine will play the file back regardless of what format the audio is in.  When my primary weapon noise was played back, it sounded EXACTLY the same as I made it in Sound Forge.  I did NOT hear it "downmixed" to 22K or anything.  Which makes me think that FS2Open doesnt CARE what format your audio file is in to be played.  If your SOURCE file is of high quality, then it will be played at that same exact quality.  

Originally posted by Flaser

Nix - get you speakers checked, or get a better one. There is always a very notable difference between files of that quality. [/B]

I've been using a Soundblaster Audigy with custom tweaks in my environmental EQ adjustments in my system with a pair of Sony MDR V700DJ's for about two years now.  When I wore those out I switched over to a pair of Sony MDR CD780s and I can tell the difference between the two headphone's quality.  My v700DJ's had a higher dynamic range than my CD780s do.  I can tell a noticable difference between a  file at 22K 8 Bit and 22K 16 Bit, and a world of differnece with a file encoded at 11K 4 bit and 44K 16 bit.  I've also used Sound Forge as my primary audio editor for about 4 years now.  I know how to augment audio files and what the results turn out like.  Just so that we're on the same page.   I've always wanted to get ahold of the original source music files for Freespace 1 to make some sort of new package with the higher quality music.  I play that, and it almost drives me nuts to hear the music in such a low quality compared to FS2's music.  Trust me, I know the audio sounds worse than it COULD sound.  The only way to make it sound better, is to have the original sources. Changing bitrate just wont cut it.

[WMCoolmon]

Trivial Psychic, did you have an old hud_gauges.tbl in your directory? I've had no problem with it, but I've only run it in 1024x768 since I fixed it.

Has anyone else noticed any problems with the mini hull/shield display?

[mrduckman]

Originally posted by WMCoolmon
Trivial Psychic, did you have an old hud_gauges.tbl in your directory? I've had no problem with it, but I've only run it in 1024x768 since I fixed it.

Has anyone else noticed any problems with the mini hull/shield display?

I have.

[Trivial Psychic]

I did in fact have a hud-gauges.tbl file in my directory.  I've since disabled it, but I haven't had the time to test to see if that fixed the problem.