64 of 32 bit

[Lynxxx]

Frequentiebereik en aliasing hebben niets te maken met de woordbreedte (aantal bits); ze hangen uitsluitend af van de samplingfrequentie.

De woordbreedte bepaalt uitsluitend de signaal-ruis verhouding.

Je hebt helemaal gelijk. Ik heb geen idee meer waarom ik deze opmerking hierbij heb geplaatst maar ik heb wat zitten knippen en plakken in mijn verhaal voordat ik dingen had gepost hier

Frequentiebereik is inderdaad uitsluitend gerelateerd aan samplerate ivm nyquist frequentie. Eventuele FM synth achtige verschijnselen en gekkigheid in lager gelegen frequenties is uitsluitend ten gevolge van die nyquist frequentie en heeft niets met woordlengte te maken.
Met aliasing bedoelde ik overigens iedere vorm van 'karteligheid' die optreedt in een gesampled signaal, ongeacht de oorzaak.

Ik weet niet of ik de oorspronkelijke post nog kan aanpassen, zo ja dan zal ik dat nog even doen

 

[DRe]

ik zal je het nog sterker vertellen lynxxx dit is je eerst post... in deze draad , grappig genoeg niet de eerste zinnige opmerking dank voor de uitleg.

 

[WaveGuide7]

Je hebt helemaal gelijk. Ik heb geen idee meer waarom ik deze opmerking hierbij heb geplaatst maar ik heb wat zitten knippen en plakken in mijn verhaal voordat ik dingen had gepost hier

Frequentiebereik is inderdaad uitsluitend gerelateerd aan samplerate ivm nyquist frequentie. Eventuele FM synth achtige verschijnselen en gekkigheid in lager gelegen frequenties is uitsluitend ten gevolge van die nyquist frequentie en heeft niets met woordlengte te maken.
Met aliasing bedoelde ik overigens iedere vorm van 'karteligheid' die optreedt in een gesampled signaal, ongeacht de oorzaak.

Ik weet niet of ik de oorspronkelijke post nog kan aanpassen, zo ja dan zal ik dat nog even doen

je FM-voorbeeld van aliasing vind ik goed gekozen: iedereen die een FM-synth heeft, kent dat typische geluid: bij een FM-toon waarvan je de frequentie laat stijgen zullen de boventonen naar boven bewegen en één voor één terugkaatsen tegen wat ik altijd de "Nyquist-spiegel" noem en dan gaan dalen en bovendien onharmonisch zijn t.o.v. de stijgende boventonen.

Misschien minstens zo instructief, vanwege z'n eenvoud, is een pure sinus laten stijgen die op zeker moment, t.g.v. de "kaatsing" tegen de Nyquist-barrière, weer gaat dalen. Met een spectrum analyzer zie je dan een paaltje eerst naar rechts schuiven en, aangekomen bij het frequentiemaximum (=Nyquist), keurig terugwandelen naar links, naar 0 Hz, om daar vervolgens weer doodleuk rechtsomkeert te maken en weer naar rechts te bewegen richting Nyquist en zo gaat die pendel eeuwig door. Dat zijn leuke dingen voor de mensch!

Hieronder WaveWizard code aliasing stijgende sinustoon. (Je kunt hezelfde ook doen met een FM-toon)
Bekijk/beluister resultaat met Scoop/SpectrumAnalyzer (menu Analyse ->Scoop en spectrum).

Sinus stijgend
  laagste frequentie (in Hz)             0
  hoogste frequentie (in Hz)             100000
  tijd in sec (0,001 - 750,0)            60
  starttijdstip in sec (0,001 - 750,0)   0
  volume (0 - 32000)                     8000
  buffer (S1, S2 of S3)                  S1
  Additief ('j' of 'n')                  n

 

[ano040425-3]

Nader onderzoek moet ik toegeven dat floating point bitrate veel beter is als fixed.

lager floating point bitrate overtreft zelfs hoger fixed point.

de dynamiek is veel hoger bij floating point maar dit maak geen verschil omdat fixed ook al meer als hoog genoeg is.
het grote voordeel bij floating point blijkt preciesie in berekeningen (meer stappen tussen waardes) en minder distortie dus ook.

Fixed point is wel veel sneller en goedkoper (goedkoper bij hardware dsp's dan).

Wel alle belang dus bij dat voor processing zoals eq's en dergelijke zo hoog mogelijke bitrate hebben
wat enkel ten goede komt van de sound

 

[WaveGuide7]

floating point bitrate

"floating point bitrate" is een hussel van dingen die niets met elkaar te maken hebben:
(1) de "bitrate" is het aantal bits per tijdseenheid, dus een begrip dat je niet kunt definiëren zonder het begrip tijd;
(2) het aantal bits in de woordbreedte daarentegen is een begrip dat ONafhankelijk is van de tijd; daar hebben we het hier over;
(3) "floating point" is een wijze van getalrepresentatie en dus onafhankelijk van de "rate" (dat de processor kloksnelheid een soms kritische rol speelt is een triviaal gegeven dat zowel geldt voor fixed als float processing).

de dynamiek is veel hoger bij floating point maar dit maak geen verschil omdat fixed ook al meer als hoog genoeg is.

Dynamiek hangt uitsluitend af van de woordbreedte, niet van de getalrepresentatie en staat dus volkomen los van het onderscheid fixed of float. De dynamiek wordt immers bepaald door de "most significant bits". Hoe je daar aan komt is een andere kwestie. Bij fixed point moet je zelf elk algoritme dat je ontwerpt heel precies doorlichten op numerieke grenzen en zelf het interne aantal benodigde bits vaststellen en het corresponderende getalsformaat definiëren en aanmaken. Bij floating point techniek heb je daar geen omkijken naar; het gebeurt allemaal automatisch op de achtergrond door de combinatie van ontwikkelsoftware (bijv. C++) en de processor. Er is dus ook in de signaalverwerking nooit discussie over geweest: floating point is veruit te prefereren. Maar alles wat je met floating doet, kun je in principe ook fixed doen; voor de dynamiek, de geluidskwaliteit, maakt het geen enkel verschil.

 

[ano040425-3]

ehm correctie, dynamiek in men post moest headroom zijn natuurlijk.. maar meer headroom kan natuurlijk een voordeel zijn voor dynamiek...

dat fixed bitrate sneller is dan floating point is wel degelijk een fact staat een beetje overal op het net...

ik dacht dus ook dat fixed bitrate (als die hoog genoeg is) geen verschil gaf VS floating,maar zoals gezegd na nader onderzoek moet ik jou tegenspreken dat er wel blijkbaar een heel groot verschil is

noisefloor,headroom,en sowieso precisie bij berekeningen omdat er meer stappen zijn,lees maar op de site van analog devices bvb of op verschillende plaatsen elders..

er is ook een soort van 'optimalizatie of verbetering' algoritme waar ze een dubbel fixed point gebruiken om de prijs te drukken (bij gebruik van hardware dsp's dus,allerhande non-audio toepassingen) maar dat is me wat ingewikkelde leesvoer.

 

[ano040425-3]

http://www.mix-engineer.com/audio-philosophy/digital-vs-analog-mixing/

'' Fixed point systems use the 32 bits in the conventional way, to provide an internal dynamic range of about 192dB. Systems that use fixed 32 bit processing (like the Yamaha desks)usually arrange for the original 24 bit audio signal to sit roughly in the middle of that 32 bit processing number to provide a lower noise floor and slightly greater headroom for the signal processing. BTW 192 dB SPL is roughly equivalent to two atmospheres pressure onthe compression of the wave and a complete vacuum on the rarefaction.

Floating point systems still use 32 bit numbers, but organise them differently. Essentially, they keep the 24 bit resolution for the audio signal, but use the remaining bits to denote a scaling factor. In other words the 24 bit resolution can be cranked up or down within a collosal internal dynamic range so that, in effect, you can never run out of headroom or fall into the noise floor -- there is something like 1500dB of dynamic range within the processing, if the maths is done properly.

Most high end consoles and workstations employ floating point maths because (if done properly) you can get better performance and quality inthe computations. Most budget/low end consoles and DAWs use fixed point processing because its easier and faster, and can be implemented in hardware more easily.
Cool Edit Pro simply converts the 16-bit data into a 32-bit float format on the way in, so that any calculations you do (EQ, gain changes, effects, etc.) have smaller cumulative errors. Simply put, if you're going to do lots of work on an audio file, the final result will sound cleaner if you give it more bits of resolution, even if you end up saving it as a 16-bit file at the end. This is the same reason that Wavelab offers 24-bit and 32-bit temporary files, even when working with 16-bit audio.''

http://www.analog.com/en/content/Fixed-Point_vs_Floating-Point_DSP/fca.html
Dynamic Range and Precision

The exponentiation inherent in floating-point computation assures a much larger dynamic range – the largest and smallest numbers that can be represented - which is especially important when processing extremely large data sets or data sets where the range may be unpredictable. As such, floating-point processors are ideally suited for computationally intensive applications.
It is also important to consider fixed and floating-point formats in the context of precision – the size of the gaps between numbers. Every time a DSP generates a new number via a mathematical calculation, that number must be rounded to the nearest value that can be stored via the format in use. Rounding and/or truncating numbers during signal processing naturally yields quantization error or ‘noise’ - the deviation between actual analog values and quantized digital values. Since the gaps between adjacent numbers can be much larger with fixed-point processing when compared to floating-point processing, round-off error can be much more pronounced. As such, floating-point processing yields much greater precision than fixed-point processing, distinguishing floating-point processors as the ideal DSP when computational accuracy is a critical requirement.

http://www.tomshardware.co.uk/forum/46221-6-floating-point-fixed-point-calculation

From what I've been reading, (The Art of Digital Audio, Mastering
> Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs"
> on Rane's website), there appears to be little doubt that as far as
> audio is concerned, fixed point calculations are superior to floating
> point calculations. 32-bit floating point predominates in our industry
> (Protools, Nuendo, DP, etc) because the calculations are cheaper to
> achieve from ready-made chips. Fixed point calculations are superior
> (i.e., more accurate), leave nothing for the chip to assume, but have
> *a lot* more work involved from the developer's point of view.

????

http://www.gearslutz.com/board/so-m...2bit-floating-point-vs-32bit-fixed-point.html


http://www.recordingmag.com/resources/resourceDetail/377.html

''We won’t get into this distinction here; certain operations benefit from fixed point math and others from floating point, with respect to accuracy and speed on different computers. More bits in your data path will almost always help you; fixed vs. floating point may or may not.''

http://www.audioecstasyproductions.com/pdfs/bitsample.pdf

http://mixonline.com/mag/audio_im_sixty_four/

http://www.ti.com/lit/wp/spry061/spry061.pdf

http://elsi-ing.pagespro-orange.fr/docs/rane%20fixed%20vs%20floating%20point%20note153.pdf

http://dsp-book.narod.ru/soundproc.pdf

 

[bikkel]

Life is a bits.

 

[dubcreator]

Gezien de meeste herrie die hier gemaakt wordt toch zo goed als plat gecompressed wordt is een dynamisch bereik van 96db ruim voldoende voor de meeste dan.
Dit staat uiteraard los van de 32 - 64 bit OS discussie.

Wel... ik blijf lekker op mn Logic 9 32bit draaien anders hebben we weer een hoop gekut met plugs. En echt geen hond die het hoort.

Heel fijn op 96k-100.000bit opnemen om vervolgens je meuk op soundcloud of andere sites te gooien en gratis te laten downloaden door de jeugd met hun Ipods enzo die de hele handel naar MP3 256 converteren en vervolgens de dag erna hem er weer af te flikkeren omdat het toch gratis is.

 

[WaveGuide7]

@egres: (#46, #47)
Dank voor links. Vluchtig doorlezend denk ik dat we een beetje over verschillende dingen praten. Ik ga het vanavond nog eens goed lezen...

 

[ano040425-3]

het is idd heel ingewikkeld of op zen minst toch onduidelijk,maar ik vind het heel interesant om te weten hoe het in elkaar zit

 

[WaveGuide7]

het is idd heel ingewikkeld of op zen minst toch onduidelijk,maar ik vind het heel interesant om te weten hoe het in elkaar zit

Nou, ik vind het helemaal niet ingewikkeld
En het zit zo in elkaar als ik hierboven al schreef.

Wat betreft je citaten:

The exponentiation inherent in floating-point computation assures a much larger dynamic range.

Fout. De dynamiek is UITSLUITEND afhankelijk van de WOORDBREEDTE. Die kun je met floating point niet groter maken. Het enig wat je met floating point wel kunt , is die dynamiek heel comfortabel opschalen of neerschalen. Dat is heel wat anders! (In je eerste citaat (Liljeblad) staat het wel goed.)

Since the gaps between adjacent numbers can be much larger with fixed-point processing when compared to floating-point processing, round-off error can be much more pronounced.

Alweer fout. Die "gaps" tussen opeenvolgende digitale waarden kun je met fixed point willekeurig klein maken, door de keuze van de interne woordbreedte, zoals al gezegd in #45; zie ook rekenvoorbeeld #32.

ik dacht dus ook dat fixed bitrate (als die hoog genoeg is) geen verschil gaf VS floating, maar zoals gezegd na nader onderzoek moet ik jou tegenspreken dat er wel blijkbaar een heel groot verschil is

Die "fixed bitrate" is, nogmaals, geen bestaande term (zie ok #45); de term komt dan ook in je citaten niet voor.
Dus ik begrijp niet goed wat je nu eigenlijk tegenspreekt. Of wat je ingewikkeld vindt.

 

[ano040425-3]

neej fixed bitrate niet ,fixed point bitrate wel,met al die links is toch wel duidelijk wat bedoeld wordt dacht ik.


Citaat:
Since the gaps between adjacent numbers can be much larger with fixed-point processing when compared to floating-point processing, round-off error can be much more pronounced.

Alweer fout. Die "gaps" tussen opeenvolgende digitale waarden kun je met fixed point willekeurig klein maken, door de keuze van de interne woordbreedte, zoals al gezegd in #45; zie ook rekenvoorbeeld #32.

dat is helemaal niet fout,lees nogmaals ,het citaat ,je maakt idd de gaps kleiner en bij fixed zijn ze groter en dat is wat er toch staat niet

 

[WaveGuide7]

Ja ik kan lezen. En ik heb het goed gelezen: wat daar staat is onzin. De afrondingsfout hoeft bij fixed point niet kleiner te zijn dan bij floating point, als je maar voldoende interne woordbreedte kiest voor je bewerkingen. Algemeen: ALLES wat je met floating point kunt, kun je ook met fixed point. Maar al het werk dat je bij fixed point "met de hand" moet doen, doet floating point automatisch. Daarom is floating point handiger.

In de jaren 90 schreef ik, voor mijn eindexamen sonologie, audiosoftware voor de Motorola DSP56001 processor. Die was fixed point. Ik programmeerde de FFT, de autocorrelatie, de Durbin-Levinson recursie, tijdvariante hoge-orde IIR-filters met 48-bits filtercoëfficiënten, toongeneratoren. Daarvoor moest ik eerst een 96-bits multiplier-routine schrijven. Waarom? Omdat die 56001 fixed point was. En allerlei ander extra werk, dat je met een floating point processor niet hoeft te doen. Maar de nauwkeurigheid en de dynamiek waren exact hetzelfde als die ik met floating point zou hebben gekregen. Het is een kwestie van berekenen en daarop de benodigde woordbreedte afstemmen. De laatste 15 jaar programmeer ik alles in C++, 64-bits floating point.

 

[ano040425-3]

hmm ja dat is wat ik dacht heel in het begin in me eerste posts (wat ik ooit had gelezen in een tijdschrift heel lang geleden) dus als de code echt goed is,kan fixed point een zelfde resultaat leveren.

ben blij te lezen dat er hier iemand is met kennis van zaken,als je alles lukraak vanop het net moet halen lees je constant tegenstrijdigheden

bedankt!

 

[WaveGuide7]

Nog een ander voorbeeld dat het misschien kan verhelderen. Neem de legendarische, zeer populaire Atari 1040 ST, de eerste home-computer (zoals dat toen heette) waarmee je een beetje leuk kon sequencen (Steinberg Pro 24). Ik werkte daarop ook veel met GFA-basic, een heel mooi programma, naar de maatstaven van toen. Alle berekeningen die je uitvoerde waren (uiteraard) in floating point, 64 bits. Maar de Atari draaide op een M68000 processor en die was, zoals alle processoren toen, fixed point. Dus alle floating point berekeningen die je in basic uitvoerde, werden door de GFA-interpreter vertaald naar fixed point M68000 assembler-instructies. Dit illustreert dat elke floating point bewerking uitdrukbaar is in fixed point, als de interpreter maar zorgt voor voldoende interne woordbreedte. Vóór de komst van floating point processoren (vanaf M96000DSP en Pentium, begin jaren 90) werd alle floating point geïmplementeerd op fixed point processoren.

 

[demian]

Ik draaide vroeger Autocad op een 8086 processor (en later op een 286) met een co-processor emulator, (anders werkte autocad niet)
Ik neem aan dat dat het zelfde principe is waar je nu op doelt, floatingpoint berekeningen uitvoeren op een 'normale' processor die daar geen hardware instructies voor heeft.
Pas vanaf de 80486 (bij pc's) was floating point een geintegreerd iets in de processor.
Amiga had 2 custom chips, maar ik heb geen idee of die floatingpoint berekeningen deden.

 

[arnomusicman]

Gezien de meeste herrie die hier gemaakt wordt toch zo goed als plat gecompressed wordt is een dynamisch bereik van 96db ruim voldoende voor de meeste dan.
Dit staat uiteraard los van de 32 - 64 bit OS discussie.

Wel... ik blijf lekker op mn Logic 9 32bit draaien anders hebben we weer een hoop gekut met plugs. En echt geen hond die het hoort.

Heel fijn op 96k-100.000bit opnemen om vervolgens je meuk op soundcloud of andere sites te gooien en gratis te laten downloaden door de jeugd met hun Ipods enzo die de hele handel naar MP3 256 converteren en vervolgens de dag erna hem er weer af te flikkeren omdat het toch gratis is.

+1

 

[Wootson]

Het is in ieder geval dusdanig complex om uit te leggen waardoor de kwestie uiteindelijk resulteert in de categorie "64 bits gebakken lucht". En inderdaad, wanneer de boel op websites met streaming content terecht komt, of op prullaria apparatuur word afgespeeld, dan had je net zo goed al die moeite kunnen besparen.

 

[bikkel]

Het blijft een raar topic vol met MAGIC_NUMBER