It wasn't so much technical burden as it was having MIDI compatibility. That's the key feature of GEMS.
It wasn't so much technical burden as it was having MIDI compatibility. That's the key feature of GEMS.
This thread needs more...ENGINEERS
They could have easily made a converter that took a MIDI file and generated GEMS data. It isn't that hard to map MIDI tracks into channels (moreover, MIDI itself has the concept of sound channels...). Then again, I think the MIDI compatibility had more to do with being able to use MIDI input devices.
Yes, the MIDI device input capability was the important aspect. There is no MID file importing, not in the GEMS tools on PC.
Death To MP3,
:3
Mida sa loed ? Nagunii aru ei saa"Gnirts test is a shit" New and growing website of total jawusumness !
And using a MIDI device really shouldn't have affected that at all. It isn't very different from using a computer keyboard to enter notes or something like that. It's pretty obvious they were just trying to be clever and failed miserably.
I wonder if that's why the Bad Apple video demo sounds so much worse in GEMS (much more so than just the 16 kHz limit causing missed samples).
Hmm, GEMS has bad PCM timing? It sounds pretty decent to me compared to many, many other examples on the system. (and some GEMS stuff is using 4-bit PCM, so some distortion isn't due to timing issues)
OTOH, perhaps it only sounds decent because other examples are so much poorer. (various SMPS Z80 examples, Capcom's driver, etc, etc)
Except there's cases like Mortal Kombat where the GEMS based MKIII/UMKIII sounds less distorted than MKI and II using the krysalis engine (with Matt Furniss), and it doesn't sound like it's just a higher sample rate issue either.
Also, I'd thought the main reason people hated GEMS was due to the limited default instrument set and resulting weak FM sound in many games (obviously more of a problem with composers with no experience with making custom FM patches).
Or do you mean it's why programmers hate GEMS? (reloading an instrument for every single note is certainly excessive . . . a tracker/MIDI sequencer set-up for the composer to change instruments per channel only when necessary should have been fine)
Edit:
It's certainly unfortunate that that's how it turned out . . . if GEMS had been designed a bit differently, it could have been far more useful and efficient. (there's also the issue of the format potentially catering better to non-FM-experienced composers by offering a broader array of instrument patches to select from and perhaps assistance for using echo/reverb, detuning, or other common effects used with FM)
I wouldn't say "not any good" . . . it wouldn't be as good as the DAC (and not as good as the AY8910) especially for mixing, but it might be decent enough to be useful -especially for optimized/custom formats catering to the specific amplitude values the PSG can handel. (some experimenting and testing would be needed to determine that -albeit, some simple calculations could give a decent idea at least, namely determining what those 816 amplitude values are -I believe Tiido determined that the SN PSG uses 2 dB steps for each volume level, so with that info one could calculate all 816 unique values)
Hmm, while it may not manage comparable SNR to an 8-bit DAC playing optimized samples, I wonder if it would be more competitive if used for cases where you actually would want better than 8-bit playback. (like ADPCM formats that cater only to ~12-16-bit output, so clipping to 8-bits might sound worse than clipping to ~10 bits and outputting to the PSG via look-up; something like 8-bit ulaw would be more questionable though, but it would be interesting to compare a custom PSG-optimized ulaw like format vs plain 8-bit PCM -the AY PSG would obviously have better results though)
There's also the limit of best quality being limited to a non-standard PCM format optimized for the PSG, but linear PCM certainly being possible as well. (albeit, since higher than 8-bit resolution mixing would add to overhead with the Z80, you probably wouldn't aim for that either -unlike the ST, where using approximated 9~12-bit output is more useful)So it offers an extra PCM but it has a price, let's see the good point and the bad point :
+ no need of Z80 software mixing for 2 channels PCM playback :
+ more Z80 time
+ less memory used (no more buffering) for a second sample play.
- quality probably not as good than using software mixing with DAC.
- require some lookup table and Z80 processing to achieve (maybe not as much than mixing though).
- can't use anymore PSG for anything else.
Conclusion : not sure it deserves it compared to a classic software mixing...
There's the additional advantage of potentially doing ALL PCM playback via the PSG and freeing all 6 FM channels to be used with PCM.
You could also choose to use only 2 PSG channels for mixing and leave 1 PSG voice (plus noise) available. That would limit quality, but be much better than 1 channel at least. (probably at least enough to play 4-bit linear samples to sound about the same as the DAC -or more optimized/custom 4-bit formatted samples sounding better, perhaps mapping in a somewhat ulaw like fashion if possible)
Another issue with ADPCM (over DPCM) would be more considerable overflow if dealing with an 8-bit domain only, though I'd imagine optimized delta tables (obviously not allowing particularly large deltas -so obviously not using a generic ADPCM format intended for 10-16-bit DAC outputAs i said previously i don't think so, i already have very limited free time and i'm not sure i can still keep the 22Khz rate. Anyway maybe 22Khz is a bit up, requiring 88 Kbits/s... but it's a standard output rate... 16 Khz offers nice quality and will lower bitrate to 64 Kbits/s and the variable delta rate will avoid important compression degradations.) and an optimized encoder would minimize those problems as well.
Chilly Willy mentioned such limiting to 8-bits on the encoder end was impractical for his CVSD examples (or even T-ADPCM), hence the use of 16-bit samples or encoding and decoding (clipped to the upper 8-bits on decoding). Though I'd have thought even a CVSD-type format (modifying deltas algorithmically rather than via fixed look-up tables) would be possible to optimize for working specifically with 8-bit sample data (encode and decode).
There are some other possibilities over direct CVSD/ADPCM alone, like Tiido's examples with explicit delta values inserted every 12 samples (8-bit delta followed by 12 2-bit samples), or instead of explicit deltas you could just insert an uncompressed 8-bit sample at regular intervals to decrease error at the expense of compression ratio. (potentially useful for ADPCM, CVSD, or DPCM)
I know Tiido uses the timers for tempo/beat timing, but I don't think he takes that route for the PCM portion. (though it could be possible to use the -relatively slow- musical beat timing to offer some limited error correction in PCM timing, if that was an issue)
Since I lack the related knowledge to contribute in any other way:
This thread needs more...ENGINEERS
GEMS? =P But yeah, no idea if it's using the timers or not. We would need to get AnalYoGirl release the source code or somebody here disassemble it >.>
I meant bad timing overall. It's completely unable to keep up with the tempo quite often (though for some games it doesn't seem to be much of an issue - Jelly Boy, anyone?).
He uses a busy loop =/ PCM playback is completely interrupted every time it parses more BGM and SFX data.
The website (when translated) says that it is using CSM mode for the vocals (I confirmed this with Regen).
For those who don't know what CSM is, it is a feature on the YM2612 that could be used for crude voice synthesis on CH3. It uses separate frequencies, like CH3's special mode, and it automatically activates key off on the channel when Timer A expires. The programmer for the demo must have overestimated the sound quality of this feature.
It is mentioned on Spritesmind
here: http://gendev.spritesmind.net/forum/...light=csm#5511
and here: http://gendev.spritesmind.net/forum/...light=csm#5639
CSM mode SHOULD sound pretty good (on real hardware). It allows for four formants, which is better than most software versions of this form of speech synthesis. Going back and listening to 0.6 again on hardware, it IS recognizable as synthesized speech, but it sounds like the programmer didn't do a good job in blending the phonemes together at the boundaries. I would bet that he currently just sets the next values for the next phoneme and starts the timer. I'm also not sure how good the fricatives are on the FM chip. That could be the source of the occasional bursts of noise.
She, we're talking about AnalYoGirl =/ (EDIT: actually, to stop with the confusion, what gender would be Minami Youichi? Assuming AnalYoGirl wrote the 2CH-PCM Z80 driver on the page)
Anyways, yeah, the special mode for the third channel was intended for speech synthesis (Yamaha advertised it as such). It doesn't do much, just lets you specify completely different frequencies for each operator (usually you can only specify a frequency and each operator gets a multiple of it). The idea is to make it easier to recreate phoneme waveforms using FM.
...the problem being that obviously that isn't the case here. As has been mentioned before, it sounds like MP3 when the quality is reduced to a ridiculous extent. It sounds more like it's trying to recreate an arbitrary PCM waveform (and completely failing at that), instead of trying to recreate the speech itself.
Speech synthesis on the YM2612 shouldn't be that bad, given that Sega could get something good with weaker hardware:
http://www.youtube.com/watch?v=KDp-iN59wLI
The main reason it sounds wrong is because consonants aren't played at the same time as the vowels (besides the Engrish-like pronunciation, lol), so the speech keeps getting cut =/ Luckily consonants are much simpler than vowels, being essentially mainly noise, so it may be possible to use the third channel for the vowels and some other channel for consonants.
EDIT: also, to be fair, the song conversion to FM really wasn't all that good for starters =P
EDIT 2: oh what the--
; PCM #1 はスタートアドレスとエンドアドレスがバンクを跨いでいると死ぬ。
; なのでバンク(32KBytes単位)を跨がない範囲に揃える必要がある。
;
; PCM #2 を使う場合はあらかじめZ80のRAMにPCMデータを転送する必要がある。
; つまり 0xA00100~0xA02000 までの 7,936Bytes しか使えない。
; スタートアドレスとエンドアドレスは 0xA00100~0xA02000 の範囲内を指定。Checking this code: http://68000.web.fc2.com/bin/pcm80dual/Z80PCM.ASM; PCM # 1 die and that across the bank start address and end address.
; Bank so (in 32KBytes) must be aligned to not cross the range.
;
; PCM # 2 If you use needs to transfer the PCM data to the RAM of the Z80 in advance.
; Only use up to 7,936 Bytes 0xA00100 ~ 0xA02000 words.
; Specify a start address and end address in the range of 0xA00100 ~ 0xA02000.
Last edited by Sik; 08-31-2011 at 10:59 PM.
Hmm, I actually hadn't noticed that too much, or maybe I jut haven't played games with really bad examples of tempo problems.
GEMS uses vblank timing for tempo, right? (so 60 Hz would be more problematic than 50 Hz in terms of Z80 timeouts)
No, .5 sounds more noisy/distorted in Gens, or at least in GensPlus, while it sounds much nicer in fusion. (not sure about real hardware)
It also doesn't sound like the same issue as the 16 kHz cut-off distortion (like is apparent when playing your CVSD demos, Stef's 22 kHz DPCM demo, or Tiido's 26 kHz demo -or TMSE- in Gens), but something different.
Hmm, interesting (I wonder if that's at all like the method used for speech synthesis in the Amy chip -though that was described as more of a type of sub-band coding conceptually similar to MPEG audio ).
Did the YM2203 also have CSM? (that would explain the odd sounding speech in PC8801 stuff)
I wonder what bitrate is used for the speech synthesis in the Bad Apple 0.6. (if it's more than 8 kbps, 1-bit CVSD might be preferable -especially as you're just encoding vocals with the instruments left as FM/PSG)
Also, the sound engine in 0.6 must be all 68k based since there's no impact from disabling the Z80 in Gens.
There are currently 1 users browsing this thread. (0 members and 1 guests)