Hello, Guest the thread was called2.4k times and contains 18 replays

last post from chiEfc0La at the

Welche Vorbearbeitung für gute Tonqualität bei Digis?

  • Welche Bearbeitungen sind sinnvoll, damit ein Digi am C64 halbwegs gut klingt und wenig rauscht?


    Was ich bis jetzt mache:


    Am PC mit Audacity:


    • Aufnehmen/hereinladen
    • Spur in Mono konvertieren
    • Sample bis zur maximalen Aussteuerung (und sogar ein bisschen mehr) verstärken
    • Heruntersamplen der Abtastfrequenz auf die Abspielfrequenz
    • Low-Pass-Filter mit halber Abtastfrequenz anwenden
    • Als 8-Bit unsigned Raw Wave speichern.

    In der Datei ist dann jedes Sample ein Byte. Dieses wandle ich in 16-Bit-Werte um (jeden Wert durch 16 dividiern und abrunden) und spiele es dann am C64/C128 ab. Beim 6581 SID reicht es wenn die Samples mit der Abspielfrequenz nach $D418 geschrieben werden.


    Um meine Frage zu konkretisieren:

    • Macht neben dem Tiefpassfilter in Audacity noch ein anderer Effekt Sinn?
    • Sollte der Tiefpass eine andere Frequenz haben (ich habe mit niedrigeren Frequenzen experimentiert, konnte hier aber keine hörbare Verbesserung erzielen)
    • Sollte beim Abspielen noch irgendein Setting in div. SID-Registern getätigt werden damit es besser klingt?
    • Sollte das Mapping 8-Bit -> 4 Bit besser nichtlinear sein?
    • Sollte beim Abspielen noch irgendein Setting in div. SID-Registern getätigt werden damit es besser klingt?

    Schau dir mal Mahoneys Methode an: https://csdb.dk/release/?id=129090&show=notes#notes


    Ist zwar SID abhängig, aber hohe Qualität dank nahezu 8Bit. Für die doppelte Datenmenge (8Bit) muss man natürlich Platz im Speicher für haben.


    Bei 4Bit macht es eigentlich bei jeder KHz-Zahl sinn, die Daten in Hi&Lo eines Bytes zusammenzupacken. Das halbiert dann den Speicherverbrauch :)

    • Sollte beim Abspielen noch irgendein Setting in div. SID-Registern getätigt werden damit es besser klingt?

    Schau dir mal Mahoneys Methode an: https://csdb.dk/release/?id=129090&show=notes#notes


    Ist zwar SID abhängig, aber hohe Qualität dank nahezu 8Bit. Für die doppelte Datenmenge (8Bit) muss man natürlich Platz im Speicher für haben.


    Bei 4Bit macht es eigentlich bei jeder KHz-Zahl sinn, die Daten in Hi&Lo eines Bytes zusammenzupacken. Das halbiert dann den Speicherverbrauch :)

    Danke, aber was ich eigentlich meinte ist was ich im Bereich der Signalvorverarbeitung tun kann. Mehr Bits durch andere Ansätze oder höhere Abspielfrequenzen sind natürlich auch fein aber die Frage ist wie man die Rohdaten am besten aufbereitet. Ich hab mir die Videos zu Mahoneys Methode angesehen, da geht es um Routinen zum Abspielen, dazu wie er die Digis vorbearbeitet habe ich nichts gefunden.

    • Aufnehmen/hereinladen
    • Spur in Mono konvertieren
    • Sample bis zur maximalen Aussteuerung (und sogar ein bisschen mehr) verstärken
    • Heruntersamplen der Abtastfrequenz auf die Abspielfrequenz
    • Low-Pass-Filter mit halber Abtastfrequenz anwenden
    • Als 8-Bit unsigned Raw Wave speichern.


    Ich habe keine erfahrung mit dem C64 speziell, nur im allgemeineren mit dieser thematik. Daher werd ich trotzdem mal etwas senf dazu schmieren, und du musst nur noch ein körnchen salz dazu tun, oderso.


    Was für eine art tonquelle wird aufgenommen? (Dynamisch) komplexe klänge oder eine einzelne stimme/sprache?
    Das aufnehmen ist nicht in mono? Wieso? Konvertieren in mono - wie? Beide spuren zusammen mischen (oft nicht so schön wg. überlagerungen) oder nur 1 spur nehmen?

    Sample "verstärken", "mehr als maximal"? Ich nehme an, du meinst dynamikkompression, nicht etwa clipping?
    Ich würde mal behaupten, um irgendwas mit 4bit abspielen zu wollen, ist kompression essentiell - außer das vorliegende signal hat schon einen passend kleinen dynamikumfang. Aber bei 4 bit... unwahrscheinlich ;D Aber audiokompresison einzustellen ist von kompressor implementation zu implementation unterschiedlich, man kann das auch verschlimmbessern - mit den einstellungen spielen und nicht drüber wundern wenn der erste versuch nicht super wird.


    Audacity down-sampling sollte doch hoffentlich bereits vor dem dezimieren tiefpass-filtern (sonst wäre es eben nur decimation, kein downsampling - wobei leute und begriffe, ja...), undzwar mit einem dafür gut geeigneten filter, vs. irgendwas, das die frei benutzbaren filterfunktionen im programm leisten, v.a. wenn nicht geeignet eingestellt.
    Kann also sein, dass "von hand" vorher zu filtern das signal insgesamt etwas verschlechtert (z.b. dumpfer als nötig).

    Was genau bedeutet denn auch "Low-Pass-Filter mit halber Abtastfrequenz anwenden"? Das resultat dieser operation muss sein, dass im spektrum der samples nichts mehr >= der späteren 1/2 abspielrate vorhanden ist.
    Solang das signal noch auf der höheren original samplerate ist, kann man das ja im FFT view von audacity begutachten. Wenn man das denn von hand filtern will - obwohl es bekloppt wäre, wenn audacity das nicht in der downsampling funktion inbegriffen bereits optimal täte - da das in einem (von user sicht) einem schritt geschieht, kann man sich natürlich das dann nicht ansehen - aber man kann im downgesampelten spektrum sehen (und ggf. hören ^^), ob es aliasing gibt. Dann weißt du ja, was los ist.


    Der C64 hat aber am SID ausgang nur ein 1st order RC filter bei -3dB @ ~ 15,9 kHz, wenn ich das recht sah.

    Ich weiß nicht, was für abspielraten ihr auf dem C64 so verwendet, aber die werden wohl weit unter 32kHz liegen - und schon für 32kHz ist ein 1st order filter der bei 1/2 davon abzufallen beginnt extrem mies als reconstruction filter.
    Ich vermute mal, dass daher gänige abspielroutinen den internen VCF entsprechend in der grenzfrequenz weit nach unten stellen und resonanz auf 0?
    Auch diese 12 dB/oct sind kein toller reconstructon filter. Könnte man wohl ein bisschen mit experimentieren, den deutlich unterhalb der 1/2 der abspielrate einzustellen, was auch den klang dämpft - aber eben auch die artefakte beim ausgeben der quantisierten samples @ samplerate.


    In der Datei ist dann jedes Sample ein Byte. Dieses wandle ich in 16-Bit-Werte um (jeden Wert durch 16 dividiern und abrunden) und spiele es dann am C64/C128 ab. Beim 6581 SID reicht es wenn die Samples mit der Abspielfrequenz nach $D418 geschrieben werden.


    4-bit ;) Wieso abrunden? Wieso nicht nearest-neighbor, e.g. kaufmännisch runden? Sollte das nicht weniger quantization noise geben, weil quantisierte kurve näher an der soll-kurve?

    Um meine Frage zu konkretisieren:

    • Macht neben dem Tiefpassfilter in Audacity noch ein anderer Effekt Sinn?
    • Sollte der Tiefpass eine andere Frequenz haben (ich habe mit niedrigeren Frequenzen experimentiert, konnte hier aber keine hörbare Verbesserung erzielen)
    • Sollte das Mapping 8-Bit -> 4 Bit besser nichtlinear sein?


    Ich habe es nie bei 4bit probiert (ok, ich habe noch nie 4bit probiert) - aber könntest mal dithering testen, falls Audacity das auf beliebige bit auflösung kann. Ansonsten, für sowas fliegt code im netz herum...
    Ich frage mich nur, ob bei 4 bit so langsam die grenze erreicht ist, wo einfach zu wenig bits da sind, dass absichtliches hinzufügen von noise einen positiven effekt haben kann :D


    Was nicht-lineares mapping betrifft - ich verstehe nicht, wie das hier helfen soll.
    Ich kenne das als verlustbehaftetes kompressionsverfahren zum sparsameren speichern oder transport über ein medium.
    Aber beim abspielen muss es ja wieder auf den größeren dynamikumfang rückkonvertiert werden - und wenn der SID nur 4 bits abspielen kann (noch dazu über einen schmutzigen hack ^^), dann helfen da mehr bits auch nicht.

  • Quote from sidfan

    4-bit ;) Wieso abrunden? Wieso nicht nearest-neighbor, e.g. kaufmännisch runden? Sollte das nicht weniger quantization noise geben, weil quantisierte kurve näher an der soll-kurve?

    Danke für den Hinweis, der Fehler ist mit nearest-neighbor sicherlich geringer und noch dazu ist diese Feature ganz leicht implementierbar.

    Quote from sidfan

    Ich habe es nie bei 4bit probiert (ok, ich habe noch nie 4bit probiert) - aber könntest mal dithering testen, falls Audacity das auf beliebige bit auflösung kann. Ansonsten, für sowas fliegt code im netz herum...
    Ich frage mich nur, ob bei 4 bit so langsam die grenze erreicht ist, wo einfach zu wenig bits da sind, dass absichtliches hinzufügen von noise einen positiven effekt haben kann :D

    Gute Idee, werde ich probieren, danke! Du hast schon recht, supertolle Samples werden das bei 4 Bit sicherlich nicht werden, aber ich brauchte die 4 Bit weil dass für ein Release war wo der C128 Samples in BASIC (!) abspielt, und ich wollte das Ergebnis noch möglichst hörbar machen. Der Witz daran war nicht die Qualität sondern die Art des Players (siehe https://csdb.dk/release/?id=192738)

    Quote from sidfan

    Was nicht-lineares mapping betrifft - ich verstehe nicht, wie das hier helfen soll.
    Ich kenne das als verlustbehaftetes kompressionsverfahren zum sparsameren speichern oder transport über ein medium.
    Aber beim abspielen muss es ja wieder auf den größeren dynamikumfang rückkonvertiert werden - und wenn der SID nur 4 bits abspielen kann (noch dazu über einen schmutzigen hack ^^), dann helfen da mehr bits auch nicht.

    Da hatte ich mich unklar ausgedrückt, meine Frage war ob das korrekte Mapping auf die vier Lautstärken-Bits beim SID linear oder an eine Nichtlinierität anzupassen wäre. Antwort: es gibt eine nichtlinieare Komponente, ich habe meinen SID ausgemessen und eine entsprechende Kurve erstellt. Wobei wahrscheinlich jeder SID da ein bisschen anders ist...


    P.S.: Willkommen sidfan im forum64 und danke für deinen hilfreichen Beitrag!

  • Hier mal ein Beispiel Sample als SuperCPU-Snapshot. Im Moment läuft das leider nur mit der SuperCPU. Ich kann den Code auch an so anpassen, dass dieser mit einem standart C64 läuft.

    Zudem sollen auch nur die Klangeigenschaften hervorgehoben werden.


    Beide Dateien runterladen, die .txt Endungen entfernen und mit 7zip entpacken. WinVice-SCPU starten, SID-Emulation auf ReSID einstellen dann den Snapshot laden und enter drücken.

    Das Sample ist ein wenig leise, aber mehr war verzerrungfrei mit dem jetzigen Code nicht möglich.


    Vielleicht kannst du damit ja etwas anfangen.

  • Grade getestet, hört sich hervorragend an! Schade dass ich keine SuperCPU in der Originalhardware habe.


    Meine Frage ist aber eigentlich wie man ein Audio am besten bearbeitet, wenn Player und Abspielrate vorgegeben sind.


    Welche Bearbeitungsschritte hast du durchgeführt um das Sample sauber hinzukriegen? Ich nehme an du hast einen Tiefpass vor dem Heruntersamplen verwendet. Wie steil hast du den Tiefpass eingestellt und auf welche Frequenz im Vergleich zur Abspielfrequenz?

  • Das habe ich alles mit selbstgecodeten Tools gemacht. Einzig die MP3 hatte ich mit Wavelab in eine Puls-Code-Modulation-Datei mit 16Bit, 44100 Hertz gewandelt. Ich bin schon eine Weile am Suchen nach den Quellcodes.

    Ich hatte mir das vor c.a. 2 Jahren mal für die SCPU gecodet um zu sehen, was da so möglich ist. Auch hatte ich einen Player halb fertig, der Vektorquantisierung unterstützte. Leider habe ich nur 2 Arme

    und einen Kopf und konnte nicht alles gleichzeitig machen. Also 1581 und Easyflash Anpassungen oder SID-Playroutine und Konvertirung. Ich entschied mich für ersteres. Wenn ich die Quellcodes finde,

    lade ich diese hier hoch. Alle anderen Infos stehen in dem Worksheet zu den Quellcodes. Ich muss diese nur noch finden.:)


    Anhang: 2 weitere Samples, aber anders/besser nachbearbeitet.

  • 4-bit ;) Wieso abrunden? Wieso nicht nearest-neighbor, e.g. kaufmännisch runden? Sollte das nicht weniger quantization noise geben, weil quantisierte kurve näher an der soll-kurve?

    Ich denke, dass kaufmännisch Runden nicht gut ist.

    - Letztlich sollen 16 "Streifen". über die Kurve gelegt werden.

    - Nur Zahlen von 0 bis 0,5 werden zu 0 gerundet, der Streifen 0 wäre sehr schmal.

    - Auf der anderen Seite würde alles von 14,5 bid 15,999 zu 15 gerundet, der Streifen 15 wäre sehr breit.

    - Durch Abrunden bekommt man 16 gleich streife Breiten, in denen die Samplewerte zusammengefasst werden.


    Letztlich ist kaufmännisches Runden ja auch nur normales abrunden, nachdem man 0,5 addiert hat. Für echte Zahlen ne prima Sache, aber für das Nachbilden einer Kurve? Ich denke, die konkreten Zahlen werden da nicht so viel Bedeutung haben. Bisschen vorher an der Lautstärke gedreht, und die Zahlen sind andere.


    2 spontane Ideen, falls Du Bock auf Experimente hast:

    - Klingt es vielleicht besser, wenn die "Streifen" über der Samplekurve gar nicht gleich breit sind, sondern im Ergebnis alle 16 Samplewerte gleich häufig vorkommen? Kenne ich im grafischen Bereich als "Histogramm equalisieren". Wenn Du also 16.000 Samples hast, dann nimm solange $00, $01, $02..., bis Du 1000 erreicht hast. Die werden dann alle zu $0.

    - Markiere vorher lokale Minima und Maxima. Die einen Abrunden, die anderen Aufrunden.

    - Die beiden Versuche lassen sich auch kombinieren: Erst die Minma $00, dann die normalen $00, dann die Maxima $00, dann die Minima $01... bis 1000 beisammen sind.

    obwohl es bekloppt wäre, wenn audacity das nicht in der downsampling funktion inbegriffen bereits optimal täte

    Meine Google-Treffer sagen, dass Audacity einen guten Filter beim Downsamplen einsetzt.
    Dürfte also eine gute Idee sein, auf einen Extra-Tiefpass vorher zu verzichten.

  • 4-bit ;) Wieso abrunden? Wieso nicht nearest-neighbor, e.g. kaufmännisch runden? Sollte das nicht weniger quantization noise geben, weil quantisierte kurve näher an der soll-kurve?

    [...]
    Letztlich ist kaufmännisches Runden ja auch nur normales abrunden, nachdem man 0,5 addiert hat. Für echte Zahlen ne prima Sache, aber für das Nachbilden einer Kurve? Ich denke, die konkreten Zahlen werden da nicht so viel Bedeutung haben. Bisschen vorher an der Lautstärke gedreht, und die Zahlen sind andere.


    obwohl es bekloppt wäre, wenn audacity das nicht in der downsampling funktion inbegriffen bereits optimal täte

    Meine Google-Treffer sagen, dass Audacity einen guten Filter beim Downsamplen einsetzt.
    Dürfte also eine gute Idee sein, auf einen Extra-Tiefpass vorher zu verzichten.


    Den einwand verstehe ich nicht. Runden soll ja bewirken, dass die benutzten endwerte eine kurve bilden, die insgesamt, und auch vom maximalen fehlerausschlag, möglicchst wenig weit weg von der originalkurve sind. Wenn man immer wie ein sturer hund abrundet, selbst bei 1,999999, dann ist der größtmögliche resultierende fehler in einem sample fast 1, während er beim runden nur 0,5 ist. 6dB unterschied. Die resultierende kurve ist also stärker verzerrt, d.h. sein spektrum underscheidet sich größer als mit der gerundeten version.
    Hier mal ein 4bit beispiel eines 250 Hz sinus bei 8192 samplerate:
    trunc-vs-round.png

    Die nicht umsonst rote kurve ist viel "verbeulter" als die grüne ;)


    Was die audiacity info betrifft - gut zu wissen! Das wäre ja sonst auch sch....aaaade :D

  • Ah, Du setzt die 0 in die Mitte der Kurve, während ich die Null am unteren Ende der Kurve sehe.

    Ich hab auch mal ne Zeichnung gemacht, was ich meine:

    Sampling.png

    Die Kurve ist so ausgesteuert, dass sie die Werte von 0 bis 7.999 füllt.

    Dabei beachte ich gar nicht so sehr den genauen Zahlenwert, der sich beim Speichern und Abspielen ergibt.

    Mein Fokus ist mehr, dass sich viele Werte aus der Ursprungskurve später einen einzigen Wert Teilen müssen.

    Darum habe ich diese Streifen von gleicher Breite über die Kurve gelegt und mich nicht weiter drum geschert, welche Lautstärke später beim Abspielen das eigentlich bedeutet. "Zufällig" ergibt Abrunden bei diesem Koordinatensystem die richtige Zuordnung zu Streifen.


    Mit der 0 in der Mitte und dem kaufmännischen (??) Runden bekommst Du auch eine Zuordnung zu gleich breiten Streifen. Allerdings ergibt das eine ungerade Zahl von Streifen, was am C64 ziemlich Schade ist.


    Mein Vorschlag oben "...sondern im Ergebnis alle 16 Samplewerte gleich häufig vorkommen..." würde im Endergebnis den Sinus aus dem Input zu einem Dreieck im Output verformen. Das dürfte den Klang schon verändern, aber vielleicht auch mehr hohe Frequenzen rüberretten.

  • stimmt, hatte die Liste aus dem Gedächtnis rekonstruiert, das Tiefpassfiltern kommt natürlich vor dem Runtersampeln.

    Das ist auch nur notwendig, wenn man mit vorsintflutlichen Algorithmen arbeitet. Zeitgemäße Software macht das beim Resampeln so nebenbei. In den letzten Jahrzehnten hat sich die Qualität von Resamplern zum Glück massiv verbessert, aber einige miese sind immer noch im Umlauf. Wer keine wertige DAW zur Hand hat, kann z.B. SoX verwenden. Das ist ein Kommandozeilentool mit sehr hochwertigem Algorithmus. Hier gibt es eine hervorragende Datenbank mit Spektralanalysen, welche die massiven Unterschiede visuell aufzeigt:

    https://src.infinitewave.ca/

  • Nur dass deine Kurve eben nicht real so schön rund aussieht sondern verbeulter ;)

    Quote

    ungerade Zahl von Streifen

    Was die skalierung betrifft, das kann man ja so halten wie ein dachdecker - dass ich nun +/-127 genommen habe war bequemlichkeit.
    Das ist ein unbenutztes LSB, verschenkt bei 4bit ca. 0,56 dB. Versus +2,5 dB rotz nehm ich das gern ^^ (s.u., noise)
    Aber kann man ja auch so skalieren - mit rundung oder nicht hat das ja nichts zu tun:
    trunc-vs-round.png


    Siehe am linken rand die skala - oben geht's nicht ganz ran, weil nur bis 127. Das ist also +/- 127,5 ausschlag, um -0.5 verschoben, damit es auf ganze zahlen kommt. (als unsigned wären das eben 0..255 voll ausgenutzt, die mitte wäre bei 127,5 und wird so nie getroffen, was ja wurscht ist.)
    -> das sind also mit 4 bit aufgelöste samples, weil man die diskrepanz zur originalkurve gut sieht, aber wieder auf 8bit gehievt damit ichs auch in Audacity importiert bekomme ;)

    Ich hab davon mal eine sekunde in Audacity importiert, und in dessen FFT fenster die werte exportiert.

    Die inherenten THD+N (0..4kHz) in den samples durch diese behandlung:

    4 bit, gerundet : -20,3 dB

    4 bit, abgeschn.: -17,8 dB

    4 bit sind so schon schrecklich genug, mehr harmonic distortion hinzuzufügen (wie durch unnötig starkes verbiegen der kurve), tut ja nicht not.

  • Ich verstehe die Grafik.

    Ich habe drübergezeichnet, was ich meine.

    Bänder 2.png

    Links:

    Das Gitter hat 16 waagerechte Linien.

    Die Punkte, die Du ausgerechnet und mit einer Linie verbunden hast, finden sich immer genau auf diesen Linien.

    Gelb/Rot sind die Bereiche, in denen das Runden zu diesen Linien wirkt. Das ist das, was ich "Streifen" nenne.

    Oberster und unterster Streifen sind halb so breit, dafür sind die 14 übrigen etwas breiter.


    Rechts:

    Das Gitter hat 16 Zwischenräume (also 17 Linien).

    Die Zuordnung ist nicht zu Linien, sondern zu diesen Streifen.

    Wenn ich für diese Streifen einen konkreten Wert geben müsste, dann wäre das der Durchschnittswert.

    Für diesen Durchschnittswert habe ich die schwarzen Punkte eingezeichnet, die oft weit von der roten Linie entfernt sind.

    Das ergibt sich recht einfach, wenn man unsigned rechnet und die Null unten ist.

    Abrunden oder die unteren 4 Bits löschen.

    Dann noch 8 addieren, damit die Punkte nicht am Rand, sondern in der Mitte der Streifen liegen.


    Frag nicht, wie man das in Audacity macht...

  • halloele!


    ...etwas abgeschieden der thread hier.

    schaetze ein:"huhu bin neu hier--hoppshopps" ...bau ich doch mit ein; but hidden


    ersma-zum-icke:

    bin professioneller musikant seit 2.hlf 80; strt on commy64

    but discovered me begeisterung (+auch petit bessesenheit) sum years earlier.

    mit den details der samplei hab ich mich seit dem, gern auch mit nix andere, naeher befasst.


    was 8bit-cpu digi angeht bin ich zwar sehr raus und kenn viele neueren techniken nur vom nebenbeiwoher;

    ich versuch mal mein glueck1 ;)



    ich fang mal hinten an... txt; ladmadown; liest du spaeter; mein senf unten ab "hier"

    the digi artikel from c=hacking 20 and 21.7z


    hab ich von http://www.ffd2.com/fridge/chacking/

    gibbet auch hier https://codebase64.org/doku.php?id=base:demo_programming

    ...und noch haufenweise anderes interressantes derart.


    die https://csdb.dk/forums/ sind neben diesem hier auch recht nuetzlich.


    in den txten !!prt1-3*.txt steht alles drinn was man zum thema $d418 smpl-plyback gut gebrauchen kann.

    (+einiges mehr;just drop it from point of nounderstand+-fun)


    zu den texten sind auch binaries beigefuegt. die hab ich mir gezz nich angesehen, kann ich nix zu sagen.

    aber schaetze, dass diese in verbindung mit dem txt nachvollziehbar sind.


    aber diese codes hatt ich mir mal naeher angesehen:

    https://github.com/Jeff-Birt/Digi_Player/archive/master.zip

    von

    https://github.com/Jeff-Birt/Digi_Player.git


    hab speziell diesen nicht ausprobiert; sollte aber funktionieren:

    ...verschiedene $d418 routinen; ausfuehrlich kommentiert

    daraus wird auch verstaendlich wie der player zur abtastrate zu timen ist.


    HIER!

    erstma per klassich $d418 kannst du max 4bit abspielen. (auf jeder maschine die ton/beep kann)

    beliebter weil klingt besser:

    du kannst natuerlich sample=bits als rechteck-waveforms abbilden...

    am 64er mit der pulsewelle der sid voices... geht auch mit dem rauschen.

    hast du 1-3 stimmen, je nach technik.

    snd verbesser durch zuhilfenahme des sid, pwm+filter zb

    du kannst natuerlich auch digis als wellenformen in trackern benutzen, hier gibts verschiedene ansetzen,

    oder auch sid-synth-tunes in digis convertieren, verschiedene weisen+techniken.


    bei details zu vorigem kann ich dir leider nich gross weiterhelfen, schaetz ich.

    das praktische is lange her bei mir. aber mit dem material oben+den adressen solltest du problemlos finden; zas du suchst.




    allerdings habe ich mich vor ner weile mit deiner eigentlichen frage beschaeftigt; vorbereitung und downsmpling.

    hab nur so weit ausgeholt, da die auswahl des materials damit beginnt, dass du ne idee hast was exact du mit dem sample/digi vorhast.


    optimal ist natürlich wenn du die samples mit einer möglichst präzisen (am besten professionellen) soundkarte aufnimmst. ich steh auf rme-firefaces.

    ...oder einen guten hardwarersampler!


    onboard-, handy- oder auch preiswerte soundkarten (alles unter 500,00-700,00 schätz ich)

    bringen schon sehr viel schmutz und andere unschönen ecken und kanten in den sample


    das ist deswegen unschön weil...

    umso mehr die einzelnen elemente des ausgangsmaterials, geh gezz von loops aus, transparent von einander

    unterschieden sind und umso klarer die einzelnen elemente strukturiert sind, mit am besten gar keinem "staub" dazwischen...


    ...umso weniger artefakte hast du später in deinen low-res-samples

    ...wahl des ausgangsmaterials is ein entscheidender faktor


    material das in dem in der zu samplenden zeit sehr viel veränderungen, auf vielen frequenzebenen, mit den elementen quer

    alle frequenzbänder gut vermischt aufweist... klingt später trashig


    aufnehmen tust du mit so viel bit+khz wie deine technik hergibt!!

    ...ohne effekte


    und gezz brauchst du technik, die audacity glaub ich nicht bietet...

    --du brauchst einen resampler der die khz runter bringt

    --und einen dithering tool


    ich benutze hierfür wavelab... da gehört der Crystal-Resampler und das Izotope MBitDither plugin zur grundaussattung.


    der MBit ist eh super, aber für unsere zwecke hier absolut genial...

    aber der reihe nach...


    einige namhafte herstellern bieten solche tools aber auch kostenlos bis günstig an...

    kann dir leider nix zu sagen. hab meinen audiorechner nicht hier und eben nix im netz gefunden.

    (...guck ma waves oder pluginallianz oder vengeance oder schau mal beim amazona-musik-magazin)


    also die allerschlimmste qualität bekommt man wenn man einen sample einfach in ein anderes format absaved.

    tu das nicht!!


    die bits einfach eher simepl runterrechnen geht, klingt aber sch... eher nie so schon.

    ...und die abtastrate einfach nach nem muster aus zu dünnen, bringt oft interressante fx, aber nich was wir hier wollen.


    in der professionellen audio-welt finden sich ganz hervorragende algorythem und techniken. kost nicht immer was!



    die besten ergebnisse hat ich immer wenn ich:

    --als erstes lasse ich die abtastrate runter rechnen. in einem rutsch scheint hier kein problem.

    96khz oder 48khz auf 11025hz oder 8khz, zb

    das mache ich mit dem Crystal-Resampler von wavelab

    --die bits klingt besser wenn man die in mehreren schritten runter bringt.

    zb 24bit auf 16bit auf 12bit auf 8bit... das mach ich mit dem MBit von Izoptope, teil von wavelab.

    der Mbit ist hier der beste, da man hier richtig gute dither algorythmen hat aber auch das hinzufügen vom rauschen

    abschalten kann... denn: noch zusätzlich rauschen hinzufügen brauchen wir wirklich nicht.


    eigentlich kernstück jeden ditherns, das hinzufügen von rauschen. die funktion hab ich sonst noch nirgends gesehen.


    --der letze schritt von 8bit auf 4bit... das kann Mbit leider nicht. wir haben das zuletzt auch einfach runtergerechnet.

    klingt ok... ABER!


    werd das hier mal ausprobieren:

    https://csdb.dk/release/?id=6601


    ¨¨chibiru wav-tool??++



    SORRY! ...can't finish that one here. i've been called back to da dutY!


    please feel free to finish it by yourself and for yourself!! ...for sure that is no problem to ya, isn't it


    sure: there are sum big (an BIGGER) mistakes up there. i am sorry! but i am in a bit of a harry, right now

    sure: sum (maybe just one) important information is missing up there

    sure: i know sum pretty nicY netpagY more. but... you know already. though...


    thanX for ya aufmerksamkeit! (voll nett, mega-merci)

    bernard arbre