Re: state of the art atari SNDH music?
Posted: Tue Nov 05, 2019 5:36 pm
A forum about Atari 16/32 computers and their clones. This forum is in no way affiliated with Atari Interactive.
https://www.atari-forum.com/
This is normal as many trackers use three timers for effects (A/B/D) and the remaining timer is C. Timer C is also used by the OS (plus harddisk driver) for it's 200 Hz clock. If you want to play the songs without killing the OS the normal thing is to hook on to the OS 200Hz Timer-C and call the music there.leonard wrote:Worst is the music driver tick system. Some musics are not exact 50Hz music. For instance some music are 52Hz. Instead of using a 52Hz timer, a fixed 200Hz timer is used, and time to time music driver is called or skipped. So the music tick is not called at 52hz exactly. But maybe original Maxymizer music driver is using the same behavior.
Yeah I get that. But still the music driver is not called at 52hz then. it's 52hz'ish with at 200hz granularity. 52 is quite ok because it's very close to a 200 multiple. But if you use same technic for say a 73hz music, I'm sure you will "hear" the difference with a real 73hz timerevil wrote:This is normal as many trackers use three timers for effects (A/B/D) and the remaining timer is C. Timer C is also used by the OS (plus harddisk driver) for it's 200 Hz clock. If you want to play the songs without killing the OS the normal thing is to hook on to the OS 200Hz Timer-C and call the music there.
Well if you want to do a SNDH player that plays tripple timer music and keep the OS alive (for example SND Player) there isn't much choice other than try to play it on the OS 200 Hz interrupt. If you reprogram Timer C there's a risk of harddrive corruption.leonard wrote:Yeah I get that. But still the music driver is not called at 52hz then. it's 52hz'ish with at 200hz granularity. 52 is quite ok because it's very close to a 200 multiple. But if you use same technic for say a 73hz music, I'm sure you will "hear" the difference with a real 73hz timerevil wrote:This is normal as many trackers use three timers for effects (A/B/D) and the remaining timer is C. Timer C is also used by the OS (plus harddisk driver) for it's 200 Hz clock. If you want to play the songs without killing the OS the normal thing is to hook on to the OS 200Hz Timer-C and call the music there.
Code: Select all
play:
sub.w #replay_freq,counter
bpl.s .noplay
add.w #200,counter
bsr sndhfile+8
.noplay:
rts
counter: dc.w 200
Ok, so I did a test between a true 70 Hz Timer A (ok, 69.8181 Hz) and a simulated 70 Hz from the OS 200 Hz Timer C.evil wrote:Perhaps if I got time tonight I'll try find some 60+ Hz file that doesn't use all timers and setup a true interrupt and an approximated 200 Hz. It will be interesting to see if I can notice a difference
nice test! I have to admit it's same for me, I can't tell which is which. I'm surprised. I thought it will be more noticeable ( esp about some nasty jittering in the music tempo )evil wrote:I can't tell which is which.
Nice one Anders. You beat me to it!evil wrote:Ok, so I did a test between a true 70 Hz Timer A (ok, 69.8181 Hz) and a simulated 70 Hz from the OS 200 Hz Timer C.evil wrote:Perhaps if I got time tonight I'll try find some 60+ Hz file that doesn't use all timers and setup a true interrupt and an approximated 200 Hz. It will be interesting to see if I can notice a difference
Here are two recordings, please listen to them first before downloading the source with the spoiler
Method 1: http://ae.dhs.nu/tmp/replay_1.mp3
Method 2: http://ae.dhs.nu/tmp/replay_2.mp3
Here are the test sources, hopefully I didn't make too many errors.
http://ae.dhs.nu/tmp/leosndh.zip
I can't tell which is which.
It remembers to me a long discussion with Ukko, the protection used is Rob Northen because Grazey is a very good music ripperleonard wrote:I looked a bit at the 0913 music disk protection. That's quite funny actually. The protection is quite smart because it makes ripping hard even using emulator. However it "may" affect sound quality. Some part of the music driver are decoded/encoded real time using trace mode. During these parts, interrupt are disabled ( sr=$a700 ). It means that some SID voice timer could be slighty delayed. I don't think it could be noticed, but anyway it should be mentionned