Amiga.org
Amiga computer related discussion => Amiga Desktop Audio and Video => Topic started by: Ral-Clan on January 30, 2013, 02:39:23 AM
-
Hi, are there any music trackers that will output 14-bit audio, and also run on a 68000 processor Amiga?
-
OctaMED Sound Studio.
DigiBooster.
HD-Rec
There are more, but I don't remember them all.
-
OctaMED Sound Studio.
DigiBooster.
HD-Rec
There are more, but I don't remember them all.
And these will run on a stock 68000? I ask because I have OctaMed SS 1.03 and it says it needs a 68020.
HD-Rec is a pro-level DAW - where did you get the info that it would run on a stock 7MHz 68000?
-
And these will run on a stock 68000? I ask because I have OctaMed SS 1.03 and it says it needs a 68020.
HD-Rec is a pro-level DAW - where did you get the info that it would run on a stock 7MHz 68000?
Force of habit, didn't mean to mention it.
To correct my self, HD-Rec needs an 060 or PPC and it's not a tracker. :)
-
And these will run on a stock 68000? I ask because I have OctaMed SS 1.03 and it says it needs a 68020.
HD-Rec is a pro-level DAW - where did you get the info that it would run on a stock 7MHz 68000?
How much work are you prepared to do? I think you might just get four channel audio, with a bit of work.
Take your 16bit samples and split them into two 8bit samples, one containing the high order byte, the other the low order byte.
Fire up OctaMed, one of the older versions (5 I think supports the 68000), and put it in to 8Channel mode.
Now work out the channel pairs (4 Channels left, 4 channels right).
Set 2 of the left channels volume to 1, and 2 of the Right channels to 1.
Now when you load in your samples (2 for each sound, high bytes and low bytes), pair them up in the tracker with the low order bytes in the channels with a volume of 1 and the high order bytes in the normal volume channel (makes sure they are on the same side of the stereo image...
That should work... Not tried it though.
-
If there is still an older version of AHI that runs on 68000 you could in theory select a very 'rough' audio mode to do the work in, then change it to filesave 14bit when you are ready for outputting.
-
@bloodline
IIRC, 14-bit replay requires cycle exact synchronization between the paired channels that are used to play the MSB/LSB halves of your 16-bit sample. I think that the 14-bit routines bypass Paula DMA sample replay all together and give her (registers) a good poking. Either that, or they pre-fill short buffers for each channel and then trigger her to replay them directly.
Either way, I am not sure that trying the replay as channels in a tracker will work. A simple test would be to play a regular sample on a channel and it's inverse on a channel on the same side. If they cancel each other out completely (or almost completely) then your plan seems plausible. Otherwise, even a sub-millisecond latency between two channels is going to sound dreadful.
-
A simple, "No" would have been fine ;) :lol:
You are quite right, I was just thinking though a possible way to make it work... Other than the way I suggested, you would have to write your own tracker :)
-
Thanks for the replies,
I am actually quite up to snuff on the more *advanced* sound / music-recording aspects on expanded big-box Amigas, as for many years I had a big-box Amiga with AHI compatible 16-bit sound card, 68040, oodles of RAM etc. etc. and used it for MIDI and audio editing work. BUT during that time I did little work with Paula audio or trackers on low-end Amigas, so am a little rusty in that regard, hence my original question.
For the high-quality (i.e. 16 and 24 bit CD-quality work) I've since moved onto PC DAWs as the hardware is far cheaper, faster, and the quality of the software is much better (for DAW work, only, I must emphasize ). I use Reaper, for instance. I had spent many years expanding my big box Amiga so that little of the audio work I was doing on it actually used the original motherboard hardware, instead relying on third party CPU cards and AHI audio cards, etc. So I don't see the switch to PC DAWs as a move away from Amigas, as I had essentially already moved away from the hardware that made the Amiga unique when still using my Amiga.
I have decided that when I do audio composing on an Amiga, I am going to go "purely Amiga"; using only the motherboard native chipset and stock 68000 processor. So while my big box Amiga is gone, I have kept a low-end Amiga (an A500 with Hard-drive side-car and a bit of expanded RAM) as my "pure" Amiga audio workstation. I figure that if I'm going to use an Amiga - I might as well go for the full experience and use what makes that machine unique - i.e. Paula audio for that distinctive sound, and trackers. Otherwise, what's the point?
So, thanks for the clarification on 14-bit audio with a stock 680000 system. It seems that a stock A500 cannot do 14-bit audio. No problem. Like I said, I want to hear that Paula sound, anyway.
Now, to expand the question. Were there any trackers that could handle more than 4 channels of audio and would still work on an Amiga 500?
I have found Oktalyzer, but I wonder if there were any more.
I am most familiar with OctaMED SS 1.03, which would handle more than four channels, but I was running that on my 68040 A2000. I have read that version of OctaMED needs a 68020.
-
I had spent many years expanding my big box Amiga so that little of the audio work I was doing on it actually used the original motherboard hardware, instead relying on third party CPU cards and AHI audio cards, etc. So I don't see the switch to PC DAWs as a move away from Amigas, as I had essentially already moved away from the hardware that made the Amiga unique when still using my Amiga.
I never thought of it like that before. :-)
The last "semi-serious" audio work (i.e. recording some demo songs) I did on an Amiga was with HD-Rec on the A1 about eight years ago, before switching to Logic on the Mac, which is still my main DAW. I was using an SBLive sound card, on a G4 PPC, with a MIDI i/f that Alfred Faust made for me, so I suppose I had moved away from "Amiga" hardware too.
Having said that, I recently put a new CMOS in my several-years-dead-A1 to get it going again and last night downloaded the latest version of HD-Rec.
Haven't done anything with it yet, right enough.
-
- i.e. Paula audio for that distinctive sound, and trackers. Otherwise, what's the point?
Could anyone comment on this ? What makes the Paula audio distinctive ?
Surely its only as good as the sampling hardware and techniques used to capture the sounds?
The limitations of Paula (number of channels, max sampling rat, bitrate etc) can be done with any modern tracker or DAW .
I get the "SID" chip thing being analog in nature its hard to get emulation right - but paula's audio is basically all digital.
I composed music on the Amiga for years , mostly using soundstudio - using the stock hardware and a midi interface. I got some great sounds out of the machine and knew a fair few techniques for getting the best sound quality. (perhaps someone recognises my nick (polyp) )
But I never once thought the Amiga had a "unique or distinctive sound" (other than the limitations of 8bit samples) - I always thought the sound hardware could have been better - i wanted a successor to SID.
N
-
But I never once thought the Amiga had a "unique or distinctive sound" (other than the limitations of 8bit samples) - I always thought the sound hardware could have been better - i wanted a successor to SID.
I'd tend to go along with this. You could maybe argue that the method of working was unique to the Amiga but not really the sound.
-
I never thought of it like that before. :-)
The last "semi-serious" audio work (i.e. recording some demo songs) I did on an Amiga was with HD-Rec on the A1 about eight years ago, before switching to Logic on the Mac, which is still my main DAW. I was using an SBLive sound card, on a G4 PPC, with a MIDI i/f that Alfred Faust made for me, so I suppose I had moved away from "Amiga" hardware too.
Having said that, I recently put a new CMOS in my several-years-dead-A1 to get it going again and last night downloaded the latest version of HD-Rec.
Haven't done anything with it yet, right enough.
I guess I was always trying to make my A2000 more and more like all the fantastic PC and Mac DAWs I saw around me. After about the year 2000 this became an uphill battle. I was trying to accomplish this by buying more and more (expensive) hardware additions that eventually led to a system that was touchy, difficult to maintain and relied less and less on the actual Commodore hardware at the machine's heart (RTG graphics and RTG audio avoided using the custom chipset altogether).
But while my 68040 CPU card was nice, it was never going to be able to run any of the Amiga DAW packages (like Audio Evolution or HD-Rec). Purchasing an expensive, hard to find, second hand PPC card only to achieve a basic DAW level that a Pentium I from the 1990s could achieve at a fraction of the price was not a practical solution.
My machine's maxed-out 32MB of RAM was never even going to be able to edit a three minute song in stereo CD-quality WAV without resorting to Virtual Memory (which was very slow). I did manage this way for many years, but four minutes to load a song and minutes to execute every edit was bearable, but not desirable.
I did use this system until 2008, though, when yet another hardware failure eventually made me realize the lengths I would have to go to to get the thing working again.
I realized that I was trying to make the Amiga 2000 what it was not. I was trying to turn it into the equivalent of a modern PC DAW, which it couldn't be.
I've come to the realization that I had been trying to shore up the Amiga's weaknesses, when instead I should have been concentrating on what it does well - i.e. using its custom chips to full advantage and the great body of audio and tracker software that allowed musicians in the 1980s and 1990s to squeeze so much out of the stock Amiga architecture.
So that's my thinking behind setting up an A500 workstation. 8-bit parallel port sampling, trackers, DPaint for making animations to go with the music, etc. These are all things the A500 can do well. The goal is to work within, and celebrate, the machine's limits and unique abilities instead of trying to make it compete with a Modern DAW. Leave the DAW work for the PC, leave the fun 8-bit work for the Amiga.
-
I'd tend to go along with this. You could maybe argue that the method of working was unique to the Amiga but not really the sound.
Well, some argue that the Paula's non-linear output gives it a distinctive sound, but you'd have to ask more knowledgeable people about that. I think Bloodline, for instance, might have more knowledge in that respect.
-
Well, some argue that the Paula's non-linear output gives it a distinctive sound,
Yeah, those guys have better ears than me.
-
Yeah, those guys have better ears than me.
Perhaps not better ears, but probably actively looking for a distinctive quality that can be found in Paula's audio reproduction...
Her hardware does colour the audio quite a bit, and I like to use her for 8bit sample play back (though I prefer record the audio samples on my Mac with it's 24bit FireWire audio box, to ensure a clean recording).
All the old Samplers were quite distinctive, which is why I still use my Roland W-30 for all 12bit work :)
-
Thanks for the replies,
I am actually quite up to snuff on the more *advanced* sound / music-recording aspects on expanded big-box Amigas, as for many years I had a big-box Amiga with AHI compatible 16-bit sound card, 68040, oodles of RAM etc. etc. and used it for MIDI and audio editing work. BUT during that time I did little work with Paula audio or trackers on low-end Amigas, so am a little rusty in that regard, hence my original question.
For the high-quality (i.e. 16 and 24 bit CD-quality work) I've since moved onto PC DAWs as the hardware is far cheaper, faster, and the quality of the software is much better (for DAW work, only, I must emphasize ). I use Reaper, for instance. I had spent many years expanding my big box Amiga so that little of the audio work I was doing on it actually used the original motherboard hardware, instead relying on third party CPU cards and AHI audio cards, etc. So I don't see the switch to PC DAWs as a move away from Amigas, as I had essentially already moved away from the hardware that made the Amiga unique when still using my Amiga.
I have decided that when I do audio composing on an Amiga, I am going to go "purely Amiga"; using only the motherboard native chipset and stock 68000 processor. So while my big box Amiga is gone, I have kept a low-end Amiga (an A500 with Hard-drive side-car and a bit of expanded RAM) as my "pure" Amiga audio workstation. I figure that if I'm going to use an Amiga - I might as well go for the full experience and use what makes that machine unique - i.e. Paula audio for that distinctive sound, and trackers. Otherwise, what's the point?
So, thanks for the clarification on 14-bit audio with a stock 680000 system. It seems that a stock A500 cannot do 14-bit audio. No problem. Like I said, I want to hear that Paula sound, anyway.
Now, to expand the question. Were there any trackers that could handle more than 4 channels of audio and would still work on an Amiga 500?
I have found Oktalyzer, but I wonder if there were any more.
I am most familiar with OctaMED SS 1.03, which would handle more than four channesl, but I was running that on my 68040 A2000. I have read that version of OctaMED needs a 68020.
OctaMED 5 I think was the last preSound Studio version of OctaMED and ran fine on my A500.
A word of warning though, 8 channel mode isn't very nice... I would recommend sticking with 4 channel mode and doing overdubs if you need more channels :)
-
Perhaps not better ears, but probably actively looking for a distinctive quality that can be found in Paula's audio reproduction...
Her hardware does colour the audio quite a bit, and I like to use her for 8bit sample play back (though I prefer record the audio samples on my Mac with it's 24bit FireWire audio box, to ensure a clean recording).
All the old Samplers were quite distinctive, which is why I still use my Roland W-30 for all 12bit work :)
Well, as far as Paula goes, there was also the added link in the chain of a variety of parallel port, 8-bit samplers. These add their own colour to the mixture.
Even still, to my ears my 8 bit sample collection, some of which I sampled myself, some of which I didn't and some of which probably wasn't even recorded via Paula, sounded very similar when played back via different hardware to what it did on my Amiga.
I know there will be certain, specific sounds which are audibly different when played back via Paula than other 8-bit chips but my ears have never noticed this to any degree where I could say with certainty that I preferred the Paula version. This is despite around a decade of pretty-much-daily sampling and recording on the A1200.
I should also add that I can't tell the difference between a 320kbps mp3 and a 16 bit .wav either. However, there were a couple of youngsters on my sound engineering course who claimed they could. So, in my case, I think it *is* my ears (or at least how I perceive what they hear).
In such circumstances the pursuit of said, unique sounds would take me into a spiral of diminishing returns that I'm far too old to devote the time too.
-
- i.e. Paula audio for that distinctive sound, and trackers. Otherwise, what's the point?
Could anyone comment on this ? What makes the Paula audio distinctive ?
Surely its only as good as the sampling hardware and techniques used to capture the sounds?
The limitations of Paula (number of channels, max sampling rat, bitrate etc) can be done with any modern tracker or DAW .
I get the "SID" chip thing being analog in nature its hard to get emulation right - but paula's audio is basically all digital.
I composed music on the Amiga for years , mostly using soundstudio - using the stock hardware and a midi interface. I got some great sounds out of the machine and knew a fair few techniques for getting the best sound quality. (perhaps someone recognises my nick (polyp) )
But I never once thought the Amiga had a "unique or distinctive sound" (other than the limitations of 8bit samples) - I always thought the sound hardware could have been better - i wanted a successor to SID.
N
I've been saying that for years, Paula is just a simple 4 DAC IC and output through a pretty noisy bus to be quite honest. When people say they attribute the sound of some tune to an Amiga what they really mean is all those sh1t samples that everyone kept using even when they were totally inappropriate. Games companies were the worst at this to be honest, mega demos rarely used those rubbish mid 80s synth samples past, well the mid 80s to be exact. Even the filter is horrible.
And yet in 1985 on the Amiga (AKA Amiga 1000) to have effectively no sound chip and just replace it with a completely flexible 4 channel 8 bit DAC replace it with basic AM/FM control of playback was pure and utter genius. The only thing wrong with every other Amiga after the 1000 is Commodore never did the very simple trick of making 6 or 8 channel (or dual Paula) motherboards to give you enough for a game. 4 channels was fine in 1985-87 but by 1989/90 we should have had at least a simple dual Paula implementation IMO.
OR the short story....don't shoot Jay Miner and co for putting one in the Amiga (AKA A1000)...... shoot the talentless musicians and mostly the penny pinching software houses that wouldn't stretch to a purchasing sampler and renting some high quality synths from Korg et al to make new exciting 100% appropriate samples for their game soundtrack tunes.
-
IIRC, 14-bit replay requires cycle exact synchronization between the paired channels that are used to play the MSB/LSB halves of your 16-bit sample. I think that the 14-bit routines bypass Paula DMA sample replay all together and give her (registers) a good poking.
No.
14-bit audio works by using Paula's built-in for free Channel Locking function which locks 2 channels together into 1 channel. 1 of the channels provides 8-bits of data and the other channel provides 6-bits of volume control. They are fed with the normal DMA mechanism, otherwise it would be quite useless.
Either that, or they pre-fill short buffers for each channel and then trigger her to replay them directly.
Either way, I am not sure that trying the replay as channels in a tracker will work. A simple test would be to play a regular sample on a channel and it's inverse on a channel on the same side. If they cancel each other out completely (or almost completely) then your plan seems plausible. Otherwise, even a sub-millisecond latency between two channels is going to sound dreadful.
If the tracker is programmed 100% correctly then it would, in fact, work perfectly. I did it myself, not in a tracker but in whatever sample editor I was using that day. AudioMaster 3 or Audition 4 or whatever. In my test I sent my sound sample to the left speaker and my inverted sound sample to the right speaker and to my astonishment I heard silence! IMHO Using 2 8-bit channels together as a 16-bit channel works as long as the tracker replay routine is programmed 100% correctly to start the 2 channels at exactly the same time.
-
I should also add that I can't tell the difference between a 320kbps mp3 and a 16 bit .wav either. However, there were a couple of youngsters on my sound engineering course who claimed they could. So, in my case, I think it *is* my ears (or at least how I perceive what they hear).
You can hear the difference if you save the .mp3 out as a sound sample. Pick your fave sample out of the song... like a 3 second sample. Cut it out and save it as its own separate sample. Listen to it on its own. It will sound like crap. I have experienced this myself many times.
.mp3s rely on creating an aural illusion. If you have cast a Dispel Illusion spell or your mom built you with the Immunity to Illusion DNA v3.1 installed to your brain then of course you will hear the difference and .mp3s will sound worse than a normal .shn or .flac or .16sv or .wav file.
-
You can hear the difference if you save the .mp3 out as a sound sample. Pick your fave sample out of the song... like a 3 second sample. Cut it out and save it as its own separate sample. Listen to it on its own. It will sound like crap. I have experienced this myself many times.
How would this work? An MP3 uncompressed to a WAV should sound exactly the same as an MP3 being uncompressed on the fly. The should be bit for bit identical.
-
How would this work? An MP3 uncompressed to a WAV should sound exactly the same as an MP3 being uncompressed on the fly. The should be bit for bit identical.
It is bit for bit identical. That is the point. And it "sounds" perfect.
Now cut a piece out.
Listen to the piece by itself.
It will sound like crap. All kinds of weird distortion.
When you remove the illusion the distortion becomes obvious to anyone. Its weird.
-
No.
14-bit audio works by using Paula's built-in for free Channel Locking function which locks 2 channels together into 1 channel. 1 of the channels provides 8-bits of data and the other channel provides 6-bits of volume control. They are fed with the normal DMA mechanism, otherwise it would be quite useless.
That's not actually how it works though, there's no "channel locking" function in the Paula. The trick is to play the highest 8 bits on one channel at full volume and the lower 6 bits and minimum volume on the second channel. The volume control is not touched at any point.
-
It is bit for bit identical. That is the point. And it "sounds" perfect.
Now cut a piece out.
Listen to the piece by itself.
It will sound like crap. All kinds of weird distortion.
When you remove the illusion the distortion becomes obvious to anyone. Its weird.
Sorry, but I don't follow your argument. MP3 encoding is a lossy encoding format, i.e the frequencies that are removed are done so at the encoding stage. When you listen to an MP3 or de-encode one to a WAV, they should be identical. i.e. you cannot "get back" lost frequencies by un-encoding an MP3 back to a WAV.
A 3-second sound clip of an MP3 or the same 3-second clip of this mp3 converted back to a WAV should sound identical.
Granted, an mp3 is always inferior to the ORIGINAL master wav, but the two 3-second test clips both derived post-encoding process should sound the same.
-
I thought he meant take a 3 second clip from a 320 kbps mp3 and compare it to the same 3 seconds clipped from a 16 bit wav?
-
I thought he meant take a 3 second clip from a 320 kbps mp3 and compare it to the same 3 seconds clipped from a 16 bit wav?
I don't know, he would have to write his original explanation a little more clearly. Maybe I misunderstood.
-
It is bit for bit identical. That is the point. And it "sounds" perfect.
Now cut a piece out.
Listen to the piece by itself.
It will sound like crap. All kinds of weird distortion.
When you remove the illusion the distortion becomes obvious to anyone. Its weird.
It's not that weird. MP3 isn't just about conversion of amplitude/time domain to frequency/phase domain (and subsequent quantization into bands). Even before that, pretty sophisticated algorithms are applied that account for the way in which sound is perceived and also how the ear reacts to sudden changes in volume. Collectively, this is the Psychoacoustic Modelling part of the encoding and it's used to make quantitative decisions about where to discard information about sound you won't perceive well because of the state your ear and auditory cortex will be in given the most recent sounds you have just heard.
For example, when there's a sudden increase in volume, the ear physically responds by tightening the tympanic membrane, which results in a loss in sensitivity. If a quiet sound immediately follows again, your ear takes some time to relax again and the cells responsible for reporting certain frequencies will be recovering too. You won't hear the quiet part as well as you would without being exposed to the previous sound and it may be that you are especially desensitised to certain frequencies for a moment. All of these phenomena and more are used by the PM stage to work out what it can discard that you won't notice.
So, when you take a sample out of the middle of a MP3 track that's had a good PM algorithm applied, particularly if the sample comes from a region following a sudden transient change in volume, pitch change or whatever, without that preceding cue, you are left with audio encoded in a manner your ear is not expecting and you likely will notice encoding artefacts as a consequence.
-
It's not that weird. MP3 isn't just about conversion of amplitude/time domain to frequency/phase domain (and subsequent quantization into bands). Even before that, pretty sophisticated algorithms are applied that account for the way in which sound is perceived and also how the ear reacts to sudden changes in volume. Collectively, this is the Psychoacoustic Modelling part of the encoding and it's used to make quantitative decisions about where to discard information about sound you won't perceive well because of the state your ear and auditory cortex will be in given the most recent sounds you have just heard.
For example, when there's a sudden increase in volume, the ear physically responds by tightening the tympanic membrane, which results in a loss in sensitivity. If a quiet sound immediately follows again, your ear takes some time to relax again and the cells responsible for reporting certain frequencies will be recovering too. You won't hear the quiet part as well as you would without being exposed to the previous sound and it may be that you are especially desensitised to certain frequencies for a moment. All of these phenomena and more are used by the PM stage to work out what it can discard that you won't notice.
So, when you take a sample out of the middle of a MP3 track that's had a good PM algorithm applied, particularly if the sample comes from a region following a sudden transient change in volume, pitch change or whatever, without that preceding cue, you are left with audio encoded in a manner your ear is not expecting and you likely will notice encoding artefacts as a consequence.
Well, since you explained it that way... it doesn't sound weird at all. :razz: :biglaugh:
-
I don't know, he would have to write his original explanation a little more clearly. Maybe I misunderstood.
Let me say it another way:
I don't know how to magically cut sounds out of an mp3.
An mp3 is compressed. You cannot just arbitrarily cut a piece of sound out of it. The file is compressed in blocks. At a minimum you would have to cut at a block boundary.
It is a basic rule of computer science that compressed data must be UNcompressed first before you start manipulating it.
Just like you can't magically cut 3 seconds out of the middle of a .lha file. First you must UNcompress the .lha file into a normal file. Then you cut the data.
-
Sorry, but I don't follow your argument. MP3 encoding is a lossy encoding format, i.e the frequencies that are removed are done so at the encoding stage.
True of course.
When you listen to an MP3
Nobody listens to mp3s. You listen to a wav.
Your mp3 player decompresses the mp3 into a wav and then sends the wav to your speakers.
or de-encode one to a WAV, they should be identical. i.e. you cannot "get back" lost frequencies by un-encoding an MP3 back to a WAV.
Nobody claimed to get back any lost frequencies. Any lost frequencies are lost forever.
A 3-second sound clip of an MP3 or the same 3-second clip of this mp3 converted back to a WAV should sound identical.
Yes they will sound identically awful. They will sound nothing like how they sounded when you listened to the song in its entirety.
Granted, an mp3 is always inferior to the ORIGINAL master wav, but the two 3-second test clips both derived post-encoding process should sound the same.
There is only one 3 second test clip. Not 2. You are really making this confusing :)
Let me try again:
1. Save your .mp3 song file as a .wav (This is so you can CUT pieces out of it, nothing more!)
2. Pick out a kewl sample that you want to use in your new Octamed SoundStudio Remix and cut that out and save it as TestClip.wav
3. Listen to the clip you just cut. It will sound yucky.
Every time I have ever done the above steps I end up with a sample that sounds really weird and unpleasant. This is why ppl say "mp3 sux, gimme a FLAC".
-
No.
14-bit audio works by using Paula's built-in for free Channel Locking function which locks 2 channels together into 1 channel. 1 of the channels provides 8-bits of data and the other channel provides 6-bits of volume control. They are fed with the normal DMA mechanism, otherwise it would be quite useless.
I don't think this is correct. Or rather, I don't believe existing calibrated/uncalibrated cybersound drivers for Paula work this way. If they did, you have the following problem to solve, for every 14-bit output value you intend to emit:
SampleValue14 = ChannelVolume * SampleValue8
where ChannelVolume is 0-63 and SampleValue8 is -128 to 127.
The problem with this is that there are many ways to factorise the 14-bit value you want or a value close to it. As an example, suppose your target SampleValue14 is 2048 (which would represent an instantaneous value equivalent to 0.25x the maximum positive value). Do you choose
Favouring larger ChannelVolume :
ChannelVolume = 63, SampleValue8 = 32 (2016)
ChannelVolume = 63, SampleValue8 = 33 (2079)
ChannelVolume = 62, SampleValue8 = 33 (2046)
Favouring exact factorisations:
ChannelVolume = 32, SampleValue8 = 32 (2048)
ChannelVolume = 16, SampleValue8 = 64 (2048)
Favouring larger SampleValue8:
ChannelVolume = 16, SampleValue8 = 127 (2032)
ChannelVolume = 17, SampleValue8 = 120 (2040)
In this trivial case, we have 2 exact factorisations we could use and an entire spread of close approximations for the case where we favour larger channel volume or where we favour larger sample value.
You can make a lookup table, of course, but even if you did, how do you decide which pair of values to use for any given target value? Moreover, this model requires that both the channel volume and 8-bit sample values behave linearly, which they don't particularly. Such a table would also be rather large.
As far as I know, 14-bit replay uses a summed approach as follows:
SampleValue14 = ChannelVolume63 * (SampleValue16MSB) + ChannelVolume1 * (SampleValue16LSB/4)
Moreover, this summation is not perfect since the operation divides the LSB by 4 (basically discarding the least significant 2 bits of data) but only multiplies the MSB by 63, rather than 64. However, this can be rectified by replacing the second term with a small lookup of adjusted values that when summed with the MSB give a better approximation of the desired output value. Beyond that you only need to worry about the true factor by which ChannelVolume63 is than ChannelVolume1 and calibrate accordingly to get a close to linear output.
-
I don't think this is correct. Or rather, I don't believe existing calibrated/uncalibrated cybersound drivers for Paula work this way.
I believe you are correct.
Not that I have ever looked at the code or anything. So who really knows how it really works.
The channel joining method is just how I assumed it worked since that method automatically seems to provide only 14 bits of resolution. While ottomh it seemed like if you played real samples on 2 channels at once you would get 16 bit resolution.
According to what I read 14-bit replayers don't using channel-joining technique.
According to what I read it plays 2 samples at once, 1 at full volume and 1 at volume 1 (or something like that).
What I do know is that 14-bit players feel computationally heavy. They always drag down my cpu. After reading your msg I guess the 14-bit players have a ton of work they have to do.
14-bit players have to take an incoming 16-bit unsigned sample and convert it to signed, split every single 16-bit value into 2 halves (one half goes to one paula channel and the other half has to goto another paula channel). Then do all that rigamorale that u talked about in your message. Then repeat the whole process for the other side of the audio. Ugh! :)
Having to do all that stuff 88200 times a second. No wonder it drags my cpu :)
I am just happy that Paula allows this 100% perfect down to the nanosecond start-audio-on-2-channels-on-once concept to work. Whoever designed that chip got a lot of things right.
-
The channel joining method is just how I assumed it worked since that method automatically seems to provide only 14 bits of resolution.
You probably could, the only issue is in how best to factorize samples into their volume/value pairs and how you cope with the non-linearity of two factors (rather than just one).
According to what I read it plays 2 samples at once, 1 at full volume and 1 at volume 1 (or something like that).
Indeed, that's what I was alluding to. The idea is that the least significant eight bits* of the data are played on the channel at volume 1 and the most significant 8 are played at volume 63 with the channels exactly in sync. The calibration (if performed) takes care of the fact that the most significant channel isn't actually 63x times louder (when viewed linearly) than the least significant one and that the bits aren't perfectly assignable due to this fact. If both the volume controls and DACs were linear and we had 8-bit volume controls (rather than 6-bit ones), we could get a very good approximation of 16-bit for not a lot of CPU time.
*and here's the problem, the volume only goes down to ~1/64th rather than 1/256th, consequently we have to divide the LSB by 4.
The calibration, at least, doesn't result in a large lookup. It's fairly cache friendly on 040 or better.
What I do know is that 14-bit players feel computationally heavy. They always drag down my cpu. After reading your msg I guess the 14-bit players have a ton of work they have to do.
The Fast 14-bit modes weren't too bad back in the AHI 4 days. Something happened after then that made everything seem a lot slower.
14-bit players have to take an incoming 16-bit unsigned sample and convert it to signed, split every single 16-bit value into 2 halves (one half goes to one paula channel and the other half has to goto another paula channel).
Well, the 16-bit data will generally be signed, rather than unsigned. What might be more of an issue is whether or not Paula herself is responsible for changing the DAC output by reading from a Chip RAM buffer or whether it's basically PIO.
Then do all that rigamorale that u talked about in your message. Then repeat the whole process for the other side of the audio. Ugh! :)
Having to do all that stuff 88200 times a second. No wonder it drags my cpu :)
I am just happy that Paula allows this 100% perfect down to the nanosecond start-audio-on-2-channels-on-once concept to work. Whoever designed that chip got a lot of things right.
It would have been even nicer if it supported 16-bit in the first place :) Or at least support 16-bit output with 8-bit delta encoded input (which can sound very good and would have been affordable in terms of memory use).
-
It would have been even nicer if it supported 16-bit in the first place :) Or at least support 16-bit output with 8-bit delta encoded input (which can sound very good and would have been affordable in terms of memory use).
Would that have worked? If you have a particularly loud transient, that would exceed the sample delta, unless you have a very high sample rate... Which would eat up memory :-/ no matter how you look at it, if you want better than 8bit audio, it's going to cost a lot of memory...
Ahhh, just thought a bit more... You mean Paula would accept an encoded bitstream, so the loud transients would still be 16bit, but the rest of the stream would be 8bit deltas... Yeah that would have totally rocked... Basically HAM for audio :) :)
-
So....just from a hypothetical perspective then, does a stock 68000 even have the horsepower to do 14-bit audio?
I seem to recall seeing a demo a few months ago posted here on A.org (link to YouTube video) where an A500 was playing an uncompressed WAV off a hard-drive in 14-bit audio.
-
So....just from a hypothetical perspective then, does a stock 68000 even have the horsepower to do 14-bit audio?
I seem to recall seeing a demo a few months ago posted here on A.org (link to YouTube video) where an A500 was playing an uncompressed WAV off a hard-drive in 14-bit audio.
The 14bit part is not the problem on 68000, but rather what you want to play. :) Uncompressed audio is easy, and even some compressed formats. But mixing several channels in software might require too much cpu-power.
-
In a way, whether Jay Miner knew it or not at the time, he has provided you with the same facility he provided the 8bit Atari home computers via POKEY sound chip. You can have 4 8 bit resolution channels or two 16 bit ones (not the same as 8/16 bit samples...think more like Commodore 64 SID oscillators etc vs Yamaha AY/YM style sound accuracy).
So you can have stereo ie 2 channel 14 bit style quality or you can have 2 stereo/4 mono 8 bit quality sounds.
Would be nice to hear a tracker style tune using 2 14bit channels, vs the same audio with 8 bit samples to hear the difference (the samples being created digitally from a 16bit source in both cases of course).
-
The 14bit part is not the problem on 68000, but rather what you want to play. :) Uncompressed audio is easy, and even some compressed formats. But mixing several channels in software might require too much cpu-power.
Yeah, I think people were overlooking that taking paula's 4 x 8 bit channels and turning them into 2 x 14 bit channels would be a bit of a problem for a tracker.
I'm pretty sure none of the existing 8 channel mixing routines were fast enough for the 68000, but that doesn't mean it's not possible. You'll either clip or lose accuracy anyway with that many channels. 4 channels is probably doable and doesn't lose much.
The locking of channels together isn't really a problem, if they are played at the same period then they should be fetched on the same line as the dma slots are tied to the video horizontal refresh. I'm not sure if the fetching at different times is a problem as the way the audio output works is more complex than just outputting to a dac and it doesn't appear to be synced to loading the register.
-
I am not sure about the technical abilities of 14 bit output on a 68000, but I noticed that the slowdown from Octamed Soundstudio on a Amiga 1200 without expansion leads to less channels for processing. I made this track on an A1200 without expansion, and got up to 6 tracks in 14bit mode. I also used 8 track mode like on Okatalyser but found that I had more processing power over individual tracks with 14bit mode. Including echo and reverb mixing...I actually preferred making Amiga tracks with the 14bit processing format instead of 8 channel splitting between the 4 channels possible.
https://drive.google.com/file/d/0BwAjjiP66Wo2SGRXR2tSTzJxbjQ/view?usp=sharing
-
Would the Prima Megamix improve this, If it comes out? Does it use any part of Paula?