SoundTrack: SUNNY BY SECTOR/SERIOUS'97 (!)
(C) M.M.A aka UnBELIEVER/SPEED CO./XTM'98
DISCRETIZATION OF CONTINUOUS TIME HARMONIC OSCILLATION
or
DIGITAL SOUND AS IT IS
------------------------- This is not a lecture and not even a practice This is students drinking "BALTIKA" beer ------------------------- Instead of an epigraph....
* * *
Recently, a huge number of games, demos, magazines, and even system programs have fallen on our heads, in which graphics converted from other platforms (AMMY/PC) are actively used. No one is surprised anymore to see "scanned" 100 rubles, the face of the program's author, or even a naked butt (if only a butt!). However, the occasional human speech, fragments of well-known songs, or (again) simply lustful female sighs heard from the speakers of your sound device arouse interest and sometimes even surprise.
How did they put sound into the computer?
Here's how...
To begin with, a bit of theory. I won't claim to be the ultimate truth, but what is presented below is indeed the case. You can be taught these things in a university in subjects like SIGNAL TRANSMISSION THEORY, DIGITAL SIGNAL PROCESSING, and similar. I want to outline the main essence, briefly and accessibly. I hope that those educated individuals do not consider this simplified version to be lame... So, we have a signal. What it is - the wild howl of King Kong or the fiery speech of V.V. Zhirinovsky - is absolutely irrelevant. It could even be 220 volts from the outlet with a certain approach. To avoid being unfounded, I drew a piece of an unidentified signal in the picture under number one. The coordinate axes are time (horizontal) and amplitude (vertical). For those who did not understand, let me explain; if this is a voice, it changes over time and at each moment has some instantaneous amplitude (in simpler terms, volume). The process of translating this sound into the "language of digits," understandable to the machine, involves two operations - discretization and quantization.
For discretization, we need to divide the time axis into equal sections with a certain step. The discretization step is chosen arbitrarily and, as you understand, the larger it is, the better the sound quality will be. Why? Because after dividing the time axis, we begin to assume that between two adjacent strokes (fig. 2), our signal has a constant value, meaning it should be a horizontal line on the graph. As many have probably already understood, the discretization step is, in some sense, those very 4, 8, 16, 22, 44 kHz. Now, from each point (taken with the chosen step) on the time axis, we can draw a straight line and, dropping a perpendicular to the amplitude axis from the intersection point of the line and the graph, obtain some value of the signal's amplitude at that moment in time. However, to know the amplitude value at that moment, we need to mark the axis of this amplitude - to divide it with a certain step, just like we did with time. This process is scientifically called quantization. You don't need to be RST#7 to understand the importance of having the quantization step as small as possible and, consequently, having as many levels as possible. Compare figures 3 and 4. In the third one, there are only seven quantization levels, and the graph (under the signal graph) consists of large steps. In the fourth, there are already 16 levels, and the steps (if drawn) have become smaller, getting closer to the original.
By the way, the distance from the "step" to the actual point on the graph, i.e., the difference between the "real" value of the signal at this point and its quantized value, is called quantization noise. Most of the hiss that you hear from the speakers during playback of the digitization is indeed quantization noise, formed at the stage of obtaining the digitization. It is logical to assume that as the discretization step approaches zero, and the number of quantization levels approaches infinity, the noise disappears completely. This is essentially all the theory. Thus, after transformations, we get an array of instantaneous amplitude values (volume) of the signal at certain moments in time. How can we adjust the parameters of discretization and quantization so that the sound is more realistic and maximally corresponds to the original? The optimal discretization of the signal is at a frequency of 44 kHz. Where does this number come from? There is a theorem by Kotelnikov, which is both complex and simple. It states (if you think a bit) that to fully restore the signal, it must be discretized at a frequency twice that of the spectral density of the signal differing from zero. The human ear perceives sound vibrations from 2 Hz to 20 kHz, i.e., a range of 20 kHz. We multiply this by 2, getting somewhere between 40-44 kHz. Is such a playback speed achievable on a SPECCY? Of course not! Everything we hear (DIGITAL SOUND) in numerous demos and specialized music editors mainly has a frequency of 4-8 kHz. In rare cases, 15-16 kHz (one of the melodies in E'97 MUSIC COMPO) and even 22 kHz (ZY-ZY and ACTION by VAV). As an experiment, the Samara programmer MONSTR from SAGE GROUP managed to achieve such playback speeds that the digitization frequency could reach 30 kHz, and this is practically the limit of the capabilities of the standard Z80A 3.5 MHz. However, despite all these achievements, people continue to digitize sound mainly at a frequency of 8 kHz. What is the catch? The thing is that, as described above, besides the discretization frequency, there is another parameter - the number of quantization levels. By infinitely increasing one of these parameters and not changing the other, we will not achieve a radical improvement in quality! The number of quantization levels is usually measured in bits per sample; for example, the phrase "this card has five-bit sound" means that this device can reproduce sound quantized at 32 levels (%11111 = 31 + 1).
And what about SPECTRUM?
1bit - 2 levels - beeper 4bit - 16 levels - AY-CHIP 7bit - 128 levels - a series of COVOXs 8bit - 256 levels - SOUNDRIVE
Thus, if we can choose the discretization step within a wide range (programmatically), then the number of levels in our digitization is immutable (hardware) and can only be reduced (listening to 1bit sound on COVOX). Now, I think the most astute have understood that the sound for SOUNDRIVE, which takes 10 seconds on the clock, will consume in the computer's memory precisely - 10*X kHz, where X is the frequency. Of course, you want to digitize such sound at 22 kHz (especially since no one is stopping you!), but in memory, it will consume 220 KB!!! And not all devices that play more than 4bit are available - the standard is still a coprocessor! The converter and player described below are oriented precisely for it. How to obtain a digitized version of the desired sound? For this, you will need a device called ADC - analog-to-digital converter. There are a number of schemes for this device for SPECCY, but in my opinion, obtaining digitization on our native computer makes no sense. You can use a large, "professional" ADC that is literally everywhere - IBM PC. All the software existing on PC designed for digitization/processing of sound can be forced to output data in .WAV format. Moreover, since .WAV is the standard sound format for Windows, you can easily find a large number of ready-made sounds in the directories of any "Windows" program (a whole treasure trove can be found on the disk with Office'97). Having found or obtained a file on PC in .wav format, you should ensure that this sound is "eight-bit" and "mono." Sounds of 16bit and stereo are more common. They can also be converted to SPECCY, but for this, another (than the one provided below) converter is needed, plus such files will be very difficult to translate due to the large amount of redundant information. .WAV can have any sampling frequency since extra samples can be discarded already on SPECCY by "throwing away" every second byte of data. The frequency will then be reduced by half.
-----------------------------------------
A little recommendation for converting from MS-DOS to TR-DOS.
This is usually done via IS-DOS, but if the file is large, it will be difficult to convert it later - it will have to be cut. Moreover, if the file turns out to be larger than 255 sectors, even IS-DOS won’t help. I recommend using the program MSDOS-RD. This thing, although written rather buggy, allows you to copy files of any length, cutting them into equal pieces of 16384 bytes. Just remember that the file name and extension must be entered strictly in uppercase letters.
-----------------------------------------
Recalling the fact that we need only 4bit from "PC" 8bit, the task of data conversion arises. At the same time, we can be glad that in one byte after conversion, two samples will fit:
the whole byte
1010 0101 └────┴────┘
first sample second sample
It's clear that in this case, twice as much data will fit in memory. This fact cannot be but pleasing, but it will come at the cost of reduced speed. So how to convert 8bit to 4bit? The simplest and most radical method is division by 16. We take only the upper 4 bits from each "eight-bit" sample.
But there is a better way... - "RONDO" (C) Advertisement
We will isolate our bits using some approximating function. Why? To get a better sound! The approximating curve proposed below was taken by ALK from some reasons known only to him. You can try to create your own array in BASIC and see how the sound changes. Below is a picture showing our function (above) and a line reflecting the option when the first 4 bits are taken (below).
█√ л ▄√ л @▌√ л `▐√ л А▀√ л ар√ л └с√ л
The start and end of both graphs coincide, but there is a difference in the middle. This seemingly insignificant difference plays a significant role in quality.
-----------------------------------------
To obtain your approximating curve, type a program in BASIC that will build a continuous function from 0 to 255 by X and a height of no more than 16 points (on the Y axis). Then instead of the PLOT command, put POKE and, after waiting a bit, you will get an array of numbers in memory. Why am I explaining this!?! The user has already advanced! Understands in two words):
-----------------------------------------
So, first we run the converter - the procedure under the label KONVERT. The approximation table will be transferred to the screen (it can be in any other place, as long as the address is even - the lower byte #00) and the process has begun! After a few seconds, we already have a ready-to-use digitization in memory from the same address where the .wav was loaded. Its length is exactly half that of the original .wav. Now we can confidently launch the player, setting the address of the sound location and the length multiplied by two (the length of the original .wav).
HERE IT IS _S_O_U_N_D_, COMING FROM YOUR
SPEAKERS!
Playback speed can be adjusted using the label TORMOZ. However, even if the minimum value TORMOZ=1 is slow for your .wav, you can kill the very slowing procedure, gaining a few more kilohertz. You should not worry about speed now, but rather about the suspicious click at the beginning of the digitization. This is nothing but the header of the .wav, where some of its parameters were stored. We accidentally translated them and now we play them as the beginning of the sound. To get rid of this annoying click, run the procedure CORRECT, which will copy an array of numbers, representing an increasing amplitude from #00 to #0A, to the beginning of the sound. This array will completely overwrite the converted .wav descriptor, along with the annoying click. That’s basically all you need to know to start experimenting with digital sound. Perhaps some individuals will think that I presented all this in a lame way and naively consider myself a genius in sound conversion. Not at all! I just aimed to convey the truth to the majority of users in the simplest and most accessible language. To all those interested in this material, I want to give a little advice: use the "power" of the IBM PC calculator for the benefit of SPECCY and remember that besides digitizing sound, it can also be processed (noise removal/filters/effects) in a number of editors like COOL'95, SOUND FORGE, etc. The quality will improve!
This is like with graphics conversion - it can be done randomly, or you can take your time in PhotoShop!
;------------------------------------- ; WAV FILE PLAYER !; WRITTEN BY ALK/STARS OF KELADAN'97 ; CORRECTED BY M.M.A/SPEED CO.'97 ; LAST EDITION ON 10.04.98 ;------------------------------------- ; EXAMPLE OF USING THE PLAYER ; LD HL,#C000 ; ADDRESS OF THE DATA START ; LD DE,#3800*2 ; (LENGTH OF SOUND) * 2 ; CALL PLAY ; EI ; RET ;------------------------------------
TORMOZ EQU 2 ; DELAY IN PLAYBACK ; ADJUSTED DEPENDING ; ON THE SAMPLING FREQUENCY.
DATA EQU #8000 ; ADDRESS OF THE ; ORIGINAL .WAV FILE ; FOR CONVERSION
SAMP EQU #4000 ; ADDRESS OF THE APPROXIMATING ; TABLE FOR CONVERSION ; 8bit > 4bit
LENGHT EQU #8000 ; LENGTH OF THE CONVERTED .WAV ; FILE
; PLAYER
;--------------------------------------- PLAY1 PUSH HL ; FOR THE FIRST CALL PUSH DE CALL INIAY POP DE POP HL ;--------------------------------------- PLAY DI ; SUBSEQUENT CALLS PR2 CALL PLAYAY CALL INIAY RET PLAYAY EXX LD DE,#FFBF LD C,#FD LD L,8 EXX LD B,0 LPLAY LD A,(HL) MAS1 AND #F0 CT1 RRCA RRCA RRCA RRCA EX AF,AF EXX LD A,L LD B,D OUT (C),A EX AF,AF LD B,E OUT (C),A EX AF,AF INC A LD B,D OUT (C),A EX AF,AF LD B,E OUT (C),A EXX LD A,(CT1) XOR #0F LD (CT1),A LD (CT1+1),A LD (CT1+2),A LD (CT1+3),A LD A,(MAS1+1) CPL LD (MAS1+1),A RLCA AND 1 LD C,A ADD HL,BC DELAYAY LD A,TORMOZ ; REMOVE THESE LINES LPB DEC A ; FOR ACHIEVING JR NZ,LPB ; MAXIMUM SPEED DEC DE LD A,D OR E JR NZ,LPLAY RET INIAY LD HL,BUFAY XOR A LD DE,#FFBF LD C,#FD LIA LD B,D OUT (C),A LD B,E OUTI INC A CP 14 JR NZ,LIA RET BUFAY DW 1,1,1 DB 0,#3F,0,0,0 ; CAN PUT DB 0,0,0 ; #38 - C L E A N, ; BUT QUIETER!
;--------------------------------- ; CONVERTER ;--------------------------------
KONVERT LD HL,SAMPTAB LD DE,#4000 LD BC,#0100 LDIR LD HL,DATA LD DE,DATA LD BC,LENGHT LPRE LD A,(DE) CALL PREOSA RLCA RLCA RLCA RLCA LD (HL),A INC DE LD A,(DE) CALL PREOSA OR (HL) LD (HL),A INC DE INC HL DEC BC LD A,C OR B JR NZ,LPRE RET PREOSA PUSH HL LD HL,SAMP LD L,A LD A,(HL) POP HL RET
;--------------------------------------- ; TABLE FOR CONVERSION 8bit > 4bit ;--------------------------------------- ; ASSEMBLE STRICTLY FROM AN EVEN ADDRESS ; LIKE #5B00,#C000,4000, ETC. ; SIZE OF THE TABLE - #100 BYTES. ;--------------------------------------
SAMPTABLE
DEFB #00,#00,#00,#00,#00,#00,#01,#01 DEFB #01,#01,#01,#01,#01,#01,#01,#01 DEFB #01,#02,#02,#02,#02,#02,#02,#02 DEFB #02,#02,#02,#02,#03,#03,#03,#03 DEFB #03,#03,#03,#03,#03,#03,#03,#04 DEFB #04,#04,#04,#04,#04,#04,#04,#04 DEFB #04,#04,#05,#05,#05,#05,#05,#05 DEFB #05,#05,#05,#05,#05,#06,#06,#06 DEFB #06,#06,#06,#06,#06,#06,#06,#06 DEFB #06,#07,#07,#07,#07,#07,#07,#07 DEFB #07,#07,#07,#07,#07,#07,#08,#08 DEFB #08,#08,#08,#08,#08,#08,#08,#08 DEFB #08,#08,#09,#09,#09,#09,#09,#09 DEFB #09,#09,#09,#09,#09,#09,#09,#09 DEFB #0A,#0A,#0A,#0A,#0A,#0A,#0A,#0A DEFB #0A,#0A,#0A,#0A,#0A,#0A,#0B,#0B DEFB #0B,#0B,#0B,#0B,#0B,#0B,#0B,#0B DEFB #0B,#0B,#0B,#0B,#0B,#0B,#0C,#0C DEFB #0C,#0C,#0C,#0C,#0C,#0C,#0C,#0C DEFB #0C,#0C,#0C,#0C,#0C,#0C,#0C,#0C DEFB #0D,#0D,#0D,#0D,#0D,#0D,#0D,#0D DEFB #0D,#0D,#0D,#0D,#0D,#0D,#0D,#0D DEFB #0D,#0D,#0D,#0D,#0D,#0D,#0E,#0E DEFB #0E,#0E,#0E,#0E,#0E,#0E,#0E,#0E DEFB #0E,#0E,#0E,#0E,#0E,#0E,#0E,#0E DEFB #0E,#0E,#0E,#0E,#0E,#0E,#0E,#0E DEFB #0E,#0E,#0E,#0E,#0E,#0F,#0F,#0F DEFB #0F,#0F,#0F,#0F,#0F,#0F,#0F,#0F DEFB #0F,#0F,#0F,#0F,#0F,#0F,#0F,#0F DEFB #0F,#0F,#0F,#0F,#0F,#0F,#0F,#0F DEFB #0F,#0F,#0F,#0F,#0F,#0F,#0F,#0F
;-------------------------------------- ; BLOCK FOR SMOOTHING INITIAL CLICKS ; LENGTH - 22 BYTES. (C) MINE! ;-------------------------------------
CORRECT LD HL,RISING LD DE,DATA LD BC,22 LDIR RET
RISING DB #00,#01,#11,#12,#22,#23,#33 DB #34,#44,#45,#55,#56,#66,#67 DB #77,#78,#88,#89,#99,#9A,#AA DB #AA
Contents of the publication: Deja Vu #05
- Аперативчик - Max
Detailed instructions on managing the DEJA VU interface, highlighting different input methods and navigation commands. Explanation of the new and old interfaces for enhanced user experience. Discussion on additional features like frame scrolling and music management.
- Аперативчик - Max
Discussion on supporting machines with more than 128k memory, leading to separate shells for 128k and 256k systems. Testing was mainly done on Scorpion and Profi, with functionality on other models anticipated. Article includes guidance on unpacking source files and insights on using improved algorithms.
- Тема - M.M.A
This article explores the theory behind digitizing sound on ZX Spectrum, focusing on sampling and quantization processes. It provides practical insights into converting sound files using specific hardware and software. Additionally, it offers methods to enhance sound quality while working within the hardware limitations.
- Theme
The article discusses the Save Our Scene initiative aimed at uniting Spectrum users and developers to promote software distribution and enhance the scene's development.
- Charter of the Amazing Soft Making Association
Discussion of the founding charter of the Amazing Soft Making association, detailing its goals, membership criteria, and operational principles.
- Theory of Magazine Creation
The article provides a detailed guide for aspiring magazine creators, focusing on technical aspects such as interface design, memory management, text formatting, and music integration for ZX Spectrum publications.
- Solder Drop
The article provides a personal account of purchasing and using the General Sound device for ZX Spectrum, detailing installation and sound performance. It discusses the initial issues encountered and praises the enhanced audio experience in compatible games. The author encourages further software adaptation for the device and reflects on multimedia capabilities with simultaneous hardware use.
- Solder Drop
The article discusses the capabilities of Sound Forge 4.0c for professional audio processing on PCs, highlighting its extensive features such as sound editing, effects, and restoration tools.
- SOFTWARE
The article reviews the latest software developments for the ZX Spectrum from Samara, including updates to MAXSOFT SCREEN PACKER, File Commander, and new applications like S-Terminal.
- SOFTWARE - Card!nal
Review and walkthrough of the logical graphic adventure game 'Operation R.R.' with detailed level instructions. Discussion on game elements like music choice and graphic design. Mentions new coder MAX/CYBERAX/BINARY DIMENSION's involvement.
- SOFTWARE
Discussion on the current state and evolution of the demoscene, highlighting the rise of 4K intros and upcoming competitions like FUNTOP'98.
- CODING
Article discusses assembly language coding techniques for optimizing screen scrolling on ZX Spectrum, featuring example code and performance analysis.
- CODING - RLA
The article explores stack manipulation techniques during second type interrupts for graphical effects on ZX Spectrum. It discusses solutions for preserving data integrity when interrupts disrupt graphical operations. Practical examples are provided to handle stack issues efficiently.
- CODING
The article describes the MS-PACK packer and its DEPACKER, detailing usage scenarios and providing BASIC and assembly code examples for handling packed files. It emphasizes optimizing performance by allowing unpacking with interrupts enabled and separating the DEPACKER from packed files. Additionally, it includes insights on programming techniques for loading and executing BASIC files on ZX Spectrum.
- CODING
The article discusses various coding techniques for ZX Spectrum, focusing on sprite rendering, rotation algorithms, and optimization methods to enhance performance.
- ANOTHER WORLD
Discussion on the evolution of multimedia technologies and their impact on various fields, including education and entertainment. It covers advances in computer hardware and software that have facilitated the integration of audio, video, and text. The article reflects on past developments and speculates on the future of multimedia systems.
- ANOTHER WORLD
Comparison of PC and Amiga systems highlighting performance, software costs, and user experience with multimedia capabilities.
- Honor Roll
Interview with PROGRESS discusses their creative journey on ZX Spectrum and AMIGA, addressing challenges in demomaking and the current state of the scene.
- Honor Roll
The article details the activities and future projects of the Eternity Industry team, based in Kovrov, including successful releases and collaborations with other groups.
- Honor Roll
Discussion of the Artcomp'98 festival, focusing on its mail-in format and guidelines for various competitions, including demo, graphics, and music categories.
- Honor Roll
The article provides a glossary of terms used in the demo scene, explaining roles such as musician, coder, and graphician, as well as different types of demos and effects. It serves as a useful resource for understanding the terminology and dynamics of the community. This is a descriptive piece aimed at educating readers about the jargon of the demo scene.
- Honor Roll
The article discusses the issues with mouse support in various ZX Spectrum magazines and the frustrations of users when encountering compatibility problems. It critiques developers for not adhering to standards, leading to poor user experiences. The author expresses the importance of consistent improvements in software for the ZX Spectrum community.
- Honor Board
The article discusses the process of creating tricolor images for ZX Spectrum using Photoshop and a simplified approach. It outlines how to divide an image into RGB channels and convert them for use on the Spectrum. Additionally, it provides tips on how to manage the files for optimal results.
- Honor Roll
The article discusses the comparison and perspectives on various computer systems, particularly emphasizing the strengths of AMIGA over PC and advocating for appreciation of all machines.
- Seven and a Half
Article discusses the humorous absurdities and peculiarities of military training and academia, blending satire with real anecdotes and witty observations.
- Seven and a Half
The article provides a satirical manual on programming methodologies, mocking the rigidity of formal programming practices and advocating for a more creative approach to coding.
- Seven and a Half
Instructions on safe sex practices, including guidelines on eligibility, preparation, and actions during and after the sexual session, along with handling emergency situations.
- Seven and a Half
The article discusses a call for a talented artist in Krasnodar for a ZX Spectrum group, raises concerns about the unethical practices of Scorpion regarding software rights, and critiques a video review of E'97.
- Seven and a Half
The article 'Семь и 1/2' narrates a humorous picnic adventure involving the editorial team of Deja Vu, highlighting their camaraderie and mishaps while preparing a barbecue.
- Trial of the Pen
The article is a humorous take on the fictional adventures of Winnie the Pooh as he interacts with computers and friends, discussing the absurdities of technology and daily life.
- First Pen
The article discusses the new section in Deja Vu dedicated to fantasy and science fiction literature, featuring book reviews and reader participation in content creation.
- Advertisement
The article is an advertisement section from Deja Vu #05, promoting collaborations with designers and musicians for future issues, and offering various software and hardware for ZX Spectrum.
- News
The article announces the launch of a new magazine, AMIGA RULES, focused on the AMIGA computer, addressing the lack of quality Russian-language publications. It aims to provide information on programming, hardware, software, and gaming, while fostering a community among AMIGA enthusiasts. The magazine will include contributions from readers and regular updates on the AMIGA scene.
