Simple Amiga audio question.

[Karlos]

One more thought: If one could do software channel separation and sound recognition/reconstruction, I'm sure the entropy of music would be better than 0.5, but just try to write it :roflmao:

If by channel you mean left/right, then many encoders already do take advantage of the correlation between left and right to increase compression*.

If by channel you mean frequency band, then basically this is what mp3 and similar systems use.

*the encoder I wrote doesn't do mid/side band analysis. The reason for this is that the method of encoding tries to pick the best n deltas per frame of audio, using both channels anyway. As a consequence, when the channels are correlated; that is to say they have a similar range of delta values (regardless of overall phase difference between the left/right signals) then the encoder picks values equally suitable for each channel. When one channel has much more variation than the other (for instance, a loud sound in one and quiet in the other), then the louder channel dominates the pool of chosen delta values. The result being that the channel with most going on is always given a bigger share of the available "bits" than the other.

[Karlos]

With a tracked format you can easily beat 1:2 lossless compression. A MOD recorded to WAV and compressed with, say, FLAC would be much bigger than the original MOD.

This is why I don't believe that the 1:2 ratio is dictated by nature, as bubblebobble claims. People simply don't know how to do it yet, because WAV to tracked format conversion isn't exactly easy to write, especially not without neural algorithms.

Ok, now I get you. Theoretically, assuming you could perform the required convolutions to identify the individual components, this might work for a piece of music where each "channel" is played by some easily identified oscillator function (square wave, sine wave, trinagle wave). You could then translate to a format that describes how those oscillators are played over time (pitch, volume, pan) in order to be able to reproduce it using those same oscillator functions. What you have there is something like your SMF (standard MIDI file) format.

However, real music produced on real instruments does not follow this paradigm. An individual instrument can produce a near infinite variation in tonal quality depending on how it is played, never mind the complexities added by production effects.

There are only two real analysis you can do with a recorded waveform in PCM format:

1) Analyse the sample data in the time domain.
2) Perform discrete FFT to convert into the frequency domain and analyse that.

In either case, you can perform an additional analysis based on the known effects of human audio perception and head related transfer function.

[Karlos]

Please?

I can't remember. What was the question?

[Karlos]

This:

Hmm. I'm not sure it was me that told you that, but well, you should be able to load wav files straight into Soundstudio.

The RIFF WAV specification is a bit of a mess as it tried to become a multiformat container for different audio codecs and sort of failed. However, basic 8 and 16-bit linear PCM encodings are fine in Soundstudio.

You can't load 16-bit WAV data as raw because it's byteswapped and basically it will sound awful. 8-bit WAV data is, for legacy reasons, also unsigned, I believe (centred at 128, rather than 0).

[Karlos]

@XDelusion

Why do you need to convert 16-bit WAV's to 14-bit anyway? Tools like Play16 etc use AHI which does the conversion from 16-bit data to calibrated 14-bit as it plays.

If you just want to use 16-bit sample data in OctaMED, just go right a head and load the WAV into the sample editor. It should be fine.

@Thoram

I sure hope I didn't make any stupid mistakes

Just the one. The conversion from unsigned to signed should have subtracted 32768, not 128. You'd subtract 128 for 8-bit unsigned sample data.

[Karlos]

Oops! It's assembly language (language of the computer in readable text format). Seeing how this is the programming section of the forum, I thought it might be useful to you. Sorry
Playing WAVs is better done with programs that have their own 14 bit calibrated player routine, because AHI sucks for Paula, and isn't needed for this anyway. Play16 uses it's own replay routine, and Hippo player, which can also stream big WAVs, also has it's own replay routine (but I'm sure you already knew that ).
Yeah, you're completely right, of course. Guess I was typing too fast

Actually yeah, Play16 talks directly to the calibrated "cybersound" driver. However, if you have AHI, far from sucking, it performs quite well. Later versions, however, are far too cpu hungry it seems.

[Karlos]

The point is that AHI isn't needed at all for 14 bit+calibration. AHI might be cool for audio cards, but for Paula it isn't needed in my opinion (yes, that might have some small back draws, but I still don't use it)

One reason to use AHI on Paula is if you have multiple apps that need to play back audio concurrently. Think of it as a simple mixer interface to Paula.