| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Goattracker sound woes
Hey guys.
Every time I make a tune in Goattracker when I export it as .sid and play it, it sounds vastly different.
I've been bothering a couple of friends with it but nobody could help me out, so here I am.
I made a little example to illustrate the problem. This particular sng is supposed to be played at x2.
Here is an example what I hear in GT and then in sidplay2
Here is the goattracker2.71 song file
And here is my config:
Quote:;------------------------------------------------------------------------ ------
;GT2 config file. Rows starting with ; are comments. Hexadecimal parameters are
;to be preceded with $ and decimal parameters with nothing.
;------------------------------------------------------------------------------
;reSID buffer length (in milliseconds)
100
;reSID mixing rate (in Hz)
44100
;Hardsid device number (0 = off)
0
;reSID model (0 = 6581, 1 = 8580)
1
;Timing mode (0 = PAL, 1 = NTSC)
0
;Packer/relocator fileformat (0 = SID, 1 = PRG, 2 = BIN)
0
;Packer/relocator player address
$1000
;Packer/relocator zeropage baseaddress
$fc
;Packer/relocator player type (0 = standard ... 3 = minimal)
0
;Key entry mode (0 = Protracker, 1 = DMC)
0
;Pattern highlight step size
4
;Speed multiplier (0 = 25Hz, 1 = 1X, 2 = 2X etc.)
2
;Use CatWeasel SID (0 = off, 1 = on)
0
;Hardrestart ADSR parameter
$ff00
;reSID interpolation (0 = off, 1 = on, 2 = distortion, 3 = distortion & on)
3
;Hexadecimal pattern display (0 = off, 1 = on)
0
;SID baseaddress
$d400
;Finevibrato mode (0 = off, 1 = on)
1
;Pulseskipping (0 = off, 1 = on)
1
;Realtime effect skipping (0 = off, 1 = on)
1
;Random reSID write delay in cycles (0 = off)
0
;Custom SID clock cycles per second (0 = use PAL/NTSC default)
0
;HardSID interactive mode buffer size (in milliseconds, 0 = maximum/no flush)
20
;HardSID playback mode buffer size (in milliseconds, 0 = maximum/no flush)
400
;reSID-fp distortion rate
0.500000
;reSID-fp distortion point
3300000.000000
;reSID-fp distortion CF threshold
0.000100
;reSID-fp type 3 base resistance
1147036.500000
;reSID-fp type 3 base offset
274228800.000000
;reSID-fp type 3 base steepness
1.006663
;reSID-fp type 3 minimum FET resistance
16125.155273
;reSID-fp type 4 k
5.500000
;reSID-fp type 4 b
20.000000
;reSID-fp voice nonlinearity
0.961316
;Window type (0 = window, 1 = fullscreen)
0
;Base pitch of A-4 in Hz (0 = use default frequencytable)
0.000000
I've been trying with different buffer and resid settings, but to no avail.
Since all the players (including Vice) seem to sound alike, I assume I'm doing something wrong with Goattracker. Still waiting for my 1541u so can't test on real hardware sadly.
Halp pls!
i |
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
You're using out of range frequency values in the wavetable (for example F0 is not either a valid relative or absolute note.) These are not guaranteed to play the same in editor and in compiled player.
You're also using quite extreme relative note values, which may cause the relocator to bug and optimize the frequency table too aggressively. Try using the relocator option "disable optimizations".
|
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Thanks, will try at once! \o/
I admit, I was poking random numbers in, looking for interesting borderline results. |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Did both things you suggested and psid playback is almost identical now.
Thank you very much! \o/
|
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
I had exactly the same problem.. Especially when I created an instrument and inserted the notes, but when I played them back it didn't sound the same... |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
Hey!!! May 13th!!! We're bro's!!! Niiiice!!! ;) |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Quote: Hey!!! May 13th!!! We're bro's!!! Niiiice!!! ;)
*highfives!* |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
!! WYLD STALYONZ!!!! |
| |
JCH
Registered: Aug 2008
Posts: 193 |
I also had some problems today making a SID experiment (in speed 3) sound right outside of GT 2.74. I tested a packed version in Sidplay2/w v2.6, Wothke's WebSid, Hermit's jsSID, a SID plugin for XMPlay, and the VICE SID player.
Especially a snare drum in a bassline was completely different. It was almost as if the noise in GT was auto-testbit-locked and also somehow divergent. I tried adjusting a lot in the editor as well as packer attributes and command-line switches. After some tests I discovered that the noise inside GT started sounding "normal" (i.e. the same way the players agreed to) when using the -i02 switch to enable reSID distortion. I'm not sure how that makes any sense. Anyone able to clarify this?
For now, I'm just going to continue using that switch.
I also had disagreeing hard restart across the board, but this settled down when I used the value FF00 in the blue title bar instead of the default 0F00. According to the documentation, this "enables the use of an alternative play routine, where waveform is written before ADSR." This fixed side effects in WebSid and the VICE SID player.
Believe it or not, I actually miss having a real C64C (for 8580) to test SID stuff on. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
If you're using the VICE3.2 release, note that it has a new ADSR related bug, which causes difference in HR's.
However multispeeds and GT2 have always been trouble, because the editor doesn't emulate a proper C64 environment, and if your ADSR settings are tight enough, even a few cycles can make the difference for the HR behaving differently. The alternate writeorder player is more lenient.
The -i switch controls also resampling / interpolation, and it's true that noise sounds bad with the most basic setting -i0. The reSID distortion modes have always at least interpolation on, which you observe with -i2. -i1 should be relatively OK too. |
| |
JCH
Registered: Aug 2008
Posts: 193 |
Yes, I'm using WinVICE 3.2. Interesting bug.
It's actually only a standard 1x thing I'm testing. I wonder how much I can rely on SidPlay/w v2.6, because the GT test now sounds exactly the same in it.
Thanks for the input. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
SidPlay is OK in regard to proper CPU / SID write timing.
When testing with emulation, I've had most trouble with filters. But 8580 filters should be less troublesome, since they're always practically the same on each chip, and there shouldn't be a volume drop in the filtered channels like on 6581. |
| |
JCH
Registered: Aug 2008
Posts: 193 |
Excellent, I also target 8580 as everyone else these days.
On Facebook I've also been made aware of the SIDBlaster as a viable option. I'll see if I can obtain one of those. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
Quote:Believe it or not, I actually miss having a real C64C (for 8580) to test SID stuff on.
whats there not to believe? YOU _need_ a real C64 too! :) |
| |
JCH
Registered: Aug 2008
Posts: 193 |
If a SIDBlaster can do the job, I can settle with that. It takes a genuine SID chip and is probably much easier to feed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
those things are really super overrated. for anything that aims proper emulation anyways. sidblaster in particular does not provide cycle exact timing (or ANY sort of timing for that matter) so really only very simple things will work as expected. (all external SID things have this problem, except catweasel mk4 and hardsid-usb - which have their own set of problems) |
| |
JCH
Registered: Aug 2008
Posts: 193 |
Fair enough. I'll try getting one anyway, it sounds neat. =) |
| |
TheRyk
Registered: Mar 2009
Posts: 2053 |
JCH(!) hasn't got a real C64 anymore?
Unbelievable /o\ someone must help
if it's just lack of a board with 8580, there are Stereo hardware solutions that can handle also 8580 on old board layouts (normally equipped with 6580 such as ASSYs 250407 or 425), iirc even easier than vice versa (finding the 12V for old 6581 on 250469 once gave me a good pain in the ass) |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quoting Groepazsidblaster in particular does not provide cycle exact timing (or ANY sort of timing for that matter) so really only very simple things will work as expected. This is not entirely true. The hardsid api supports register write scheduling by a caller-supplied target 6510 cpu cycle count. However, the write buffering is not implemented in the device firmware, but rather in the driver program. This leads to wildly different results from machine to machine depending on the latency in the USB interface, for instance on my laptop samples play quite well, while on my workstation they sound like s**t. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
"This is not entirely true.<followed by by its true>"
and there is no PAL clock on the device either as far as i can see |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quoting Groepaz"This is not entirely true.<followed by by its true>"
and there is no PAL clock on the device either as far as i can see You're looking at the SIDBlaster purely as a hardware thing. For the user it is also a matter of software. Cycle exact timing is approximated in the driver and in many cases it works pretty well. Something like the exSID would obivously be better since it has cycle excact timing built in, but I don't think this has hardsid.dll compatibility yet. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
what are you trying to say? all i am saying is that it doesnt provide correct timing. and no other device currently on the market does, afaik.
and yes, unless it does provide 100% accuracy, in all situations, those devices are a complete waste of time and precious SIDs - and chances are emulation will do a better job. |
| |
Stone
Registered: Oct 2006
Posts: 168 |
I am trying to say that for many users, the timing approximation is good enough.
Whether or not it is a waste of time, is a matter of opinion and you are certainly entitled to yours. |
