Limon REU Wave-player

Es gibt 88 Antworten in diesem Thema, welches 18.081 mal aufgerufen wurde. Der letzte Beitrag (22. Februar 2012 um 02:55) ist von sauhund.

  • An der Stelle großes Lob, der Player funktioniert jetzt einwandfrei:

    -Bildschirm schwarz, dadurch wesentlich weniger Störgeräusche durch den VIC und andere Chip -> somit man nun problemlos lauter stellen ohne dass die Störgeräusche zu sehr nerven
    -der Player ist nun lauter als in der ersten Version, somit geraten Störgeräusche noch weiter in den Hintergrund (bei vernünftig ausgesteuertem Soundfile kaum mehr zu hören) -> noch bessere Qualität
    -Player funktioniert sowohl auf "richtig" (mit wraparound, 1541U, neue Vice-Version) als auch auf "falsch" (ohne wraparound, alte Vice-Version) emulierter REU
    -Samplingrate wird automatisch erkannt -> man muss nicht mehr darauf achten, welchen Player man laden muss, um richtige Abspielgeschwindigkeit zu erreichen
    -mehr Samplingfrequenzen werden unterstützt

    Wenn man mp3s oder Audio-CDs als Quelle benutzt, sind meines Erachtens vorallem die Frequenzen 22,05 und 44,1 kHz sinnvoll (bei 11 kHz ist die Qualität nicht allzu toll, bestenfalls für Hörbücher o.Ä. geeignet, 48 kHz macht bei Audio-CD als Quelle keinen Sinn, da hochsamplen die Qualität eher schlechter macht als besser, merke ich immer, wenn ich mp3s von Noobs anhören, die glaubten mehr sei besser ohne auf die Quellfrequenz Rücksicht zu nehmen).

    Sowohl bei diesem Player als auch beim Limonplayer gibts bei der 1541u ein kleines Problem: versucht man während des Abspielens mit der mittleren Taste ins Menü der 1541u zu gehen, friert das System ein oder man kommt zwar ins Menü, kann dann aber nichts mehr auswählen, manchmal bekommt man den C64 noch resetet, aber die 1541u lässt sich dann nur noch durch Hardreset (aus- und einschalten) "wiederbeleben".
    Dieses Problem kann man aber ganz leicht umgehen, indem man zuerst mit der rechten Taste einen Reset des C64 auslöst, sodass der Player nicht mehr läuft, danach kann man mit der mittleren Taste ganz normal ins Menü, ein neues REU-file auswählen oder was anderes machen. Wenn man dies beachtet, kann man das ganze harwareschonender betreiben (ohne Aus-an-schalten).

    **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. ****

  • Zitat

    Also auf meinem NSS hört es sich genauso an wie der Limon-player - ich höre ein lautes, vordergründiges Fiepen das fast alle anderen Geräusche im Hintergrund plattmacht - müsste für den wohl extra angepasst werden...aber ist beim Limon ja (noch) nicht anders!


    das liegt an dem schon genannten trick den der limon player benutzt um lauter zu sein (ich mache da jetzt praktisch das gleiche)

    Zitat

    Zum Klang würde ich auf die schnelle behaupten das er mit dem Limon ziemlich identisch ist


    da die innere playerloop praktisch identisch ist jetzt sollte auch die qualität praktisch identisch sein :) beim 44khz player hab ich sogar noch das timing 100% korrekt hinbekommen, da haut der limon player alle 3 samples 1 cycle daneben :)

    Zitat

    Aussetzer beim wrappen....es fehlen jedesmal ~1-2 Sek?!


    das sollte nicht sein. beim 44khz und 48khz player wird das wrapping zwar sehr dreckig in einem interrupt erledigt, wodurch es alle paar sekunden einen aussetzer von bis zu 2 samples gibt - das liegt aber nicht in der grössenordnung von sekunden, sondern eher von tausendstel sekunden und ist meisst nicht hörbar beim 44khz player höre ich das hier praktisch garnicht.

    Zitat

    Player funktioniert sowohl auf "richtig" (mit wraparound, 1541U, neue Vice-Version) als auch auf "falsch" (ohne wraparound, alte Vice-Version) emulierter REU


    apropos, zumindest die svn version von VICE hat da scheinbar einen bug der dazu führt das das wrapping manchmal daneben haut.

    Zitat

    sind meines Erachtens vorallem die Frequenzen 22,05 und 44,1 kHz sinnvoll (bei 11 kHz ist die Qualität nicht allzu toll, bestenfalls für Hörbücher o.Ä. geeignet


    jau. 48khz ist eher sinnlos, auch weil der player (im gegensatz zum 44khz player) nicht cycle-exakt ist, und daher mehr verzerrt. der gewinn an qualität dürfte daher nicht besonders hoch sein. und ja, 11khz ist vor allem für sprache interessant... da geht dann auch ein recht langes sample.

    Zitat

    Sowohl bei diesem Player als auch beim Limonplayer gibts bei der 1541u ein kleines Problem: versucht man während des Abspielens mit der mittleren Taste ins Menü der 1541u zu gehen, friert das System ein oder man kommt zwar ins Menü, kann dann aber nichts mehr auswählen, manchmal bekommt man den C64 noch resetet, aber die 1541u lässt sich dann nur noch durch Hardreset (aus- und einschalten) "wiederbeleben".


    hab ich auch gemerkt... vermutlich mag es die 1541u nicht so wenn man während einem laufenden reu-dma den menu freezer betätigt :)

  • das sollte nicht sein. beim 44khz und 48khz player wird das wrapping zwar sehr dreckig in einem interrupt erledigt, wodurch es alle paar sekunden einen aussetzer von bis zu 2 samples gibt - das liegt aber nicht in der grössenordnung von sekunden, sondern eher von tausendstel sekunden und ist meisst nicht hörbar beim 44khz player höre ich das hier praktisch garnicht.


    Habs gestern aus Zeitmangel nur kurz mit einem Lied (44,1) probiert und ner Uralt-U-Firmware - aber jetzt hab ich länger frei und werds mal weitertesten...kann ja auch mal schauen das ich ein Video hinbekomm und hochlade...gestern im Test fehlten jedoch wirklich ´ganze Stücke´ beim wrappen, der Text des Songs war regelrecht ´zerhackt´...aber ich probiers heut wie gesagt nochmal!

    Zum SwinSID:

    You can easily add SwinSID fix to PWM playback code just by removing updates of volume register for synchronization and set zero waveform once at the beggining.

    schrieb Swinkels dazu, wäre es theoretisch möglich deinen Player anhand seiner Aussage noch dementsprechend anzupassen? Oder geht das nicht so einfach?

  • Es muss an der Firmware der U oder am Hardreset liegen...wenn ich die 2.4 nehm ist es besser - die hab ich als erstes getestet, dann Hardreset und ne andere SD rein (mit ner alten 1.7*) und den Player geladen - siehe da, wieder das gleiche, es fehlen teilweise wirklich mehrere Sekunden(!)!

    Na erstmal egal, mit der 2.4er ist es besser :) Da hör ich wirklich hin und wieder (beim wrapping wahrscheinlich) nur ein leichtes Knacksen...gute Arbeit! Sind in der 1.7*-REU vielleicht noch bugs?

    Perfekt wärs natürlich wenn man die Knackser noch entfernen könnte sowie ihn auf den SwinSID anpassen könnte...aber ich hab mal deine Readme gelesen "feel free to make more out of it. i wont"...mal schauen, bin da zwar ein total-noob aber wenn die Sources schon dabei sind werd ich nacher vielleicht mal nen Blick reinwerfen :roll2:

    Vielen Dank erstmal für die Arbeit und den Player!

    EDIT: So, jetzt bin ich mir ziemlich sicher das es an der 1.7* liegt! Wenn ich nämlich die SD zurückwechsel und ohne neu zu laden den Player starte ist alles wieder gut...also ein weiterer Grund für den ein oder anderen verbleibenden 1.7*-Nutzer umzusteigen ;)

  • jo, das Problem mit dem Zerhacken hatte ich am Anfang auch, dann hat man eine fehlerhafte Firmware erwischt, bei Nuvies tritt dann ein ähnlicher Fehler auf, der werden die Bilder zerhackt...

    **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. ****

  • Zitat

    schrieb Swinkels dazu, wäre es theoretisch möglich deinen Player anhand seiner Aussage noch dementsprechend anzupassen? Oder geht das nicht so einfach?


    das macht irgendwie keinen sinn was er da sagt, weder bezüglich pwm samples noch der neuen methode (beide benutzen das volume register garnicht).
    davon ab werde ich mich hüten und software sicher nicht an verbuggte hardware anpassen. das war ja der ganze witz der aktion eben genau das nicht zu tun :=)

  • Ich habe mal einen kleinen Test mit einer Soundtest-Wave-Datei gemacht. Diese enthält einen Ton der von 20 Hz bis auf 20 kHz ansteigt.

    Diese Testdatei habe ich einmal direkt mit dem PC abgespielt und einmal in eine reu-Datei konvertiert und mittels 1541u auf dem C64 abgespielt.

    Beide male habe ich mit Hilfe des PCs den Frequenzgang aufgenommen.

    Hier das Ergebnis:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Es ist zu sehen, dass die tiefen Frequenzen bis ca. 100 Hz leiser abgespielt werden als der Rest. Ob das an der Testdatei oder an meinem Soundchip liegt, weiß ich nicht.

    Erkennbar ist auch, dass sich der Frequenzgang beider Aufnahmen in weiten Bereichen ähnelt (beim C64 ist der Ton nur leiser), d.h. bis ca. 3 kHz gibt es kaum Verfälschungen in der Lautstärke der einzelnen Frequenzen, erst bei höheren Frequenzen gibt es leichten Lautstärkeabfall und ab 8 kHz war deutliches Aliasing (Frequenzverfälschungen in die niederfrequenten Bereiche herein) hörbar. Hier scheint es wohl eine technische Grenze zu geben.

    Beim Abspielen am PC konnte ich ab ca. 15 kHz keinen Ton mehr hören, ob das an der Testdatei, meiner Soundkarte, meinem Kopfhörer oder meinen Ohren liegt, kann ich nicht sagen, ich vermute mal an der Sound"karte" (billiger Onboard-Chip), da der Ton schlagartig verschwand, in der Testdatei sind in diesem Bereich aber noch Tondaten vorhanden.

    Ich habe die Testdatei für den C64 auch auf meinen Webspace geladen, für die, die es auch mal testen wollen: Bitte melde dich an, um diesen Link zu sehen.

    Den Test habe ich nur interessehalber gemacht, das ist wahrscheinlich auch nicht allzu exakt, schließlich ist mein PC kein Tonstudio.

    **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. **** Bitte melde dich an, um diesen Link zu sehen. ****

  • interessant!

    der frequenzgang beim c64 sieht erstaunlich gut aus, da hätte ich jetzt echt schlimmeres erwartet =)

    Zitat

    Es ist zu sehen, dass die tiefen Frequenzen bis ca. 100 Hz leiser abgespielt werden als der Rest. Ob das an der Testdatei oder an meinem Soundchip liegt, weiß ich nicht.


    dafür gibt es eine einfache erklärung: in der regel wird bei audio ein- und ausgängen zur ein- bzw auskopplung (entfernung von gleichspannungsanteilen) ein kondensator in reihe geschaltet, und dieser bildet einen hochpass (zusammen mit der restlichen schaltung). dadurch werden die niedrigen frequenzen etwas gedämpft. (und je hochwertiger die ganze technik, desto weniger. für billigen consumerkram find ich das in dem bild gezeigte jetzt auch nicht tragisch)

    Zitat

    Erkennbar ist auch, dass sich der Frequenzgang beider Aufnahmen in weiten Bereichen ähnelt (beim C64 ist der Ton nur leiser), d.h. bis ca. 3 kHz gibt es kaum Verfälschungen in der Lautstärke der einzelnen Frequenzen, erst bei höheren Frequenzen gibt es leichten Lautstärkeabfall und ab 8 kHz war deutliches Aliasing (Frequenzverfälschungen in die niederfrequenten Bereiche herein) hörbar. Hier scheint es wohl eine technische Grenze zu geben.


    ja, genau. die erste grenze liegt irgendwo bei 3,8khz oder so - das ist die maximalfrequenz die der sid erzeugen kann. auf die hier benutzte abspieltechnik bezogen heisst das wiederum das das die maximale samplefrequenz ist bei der man tatsächlich mit den theoretisch möglichen 8 bit abspielen kann. durch das abwechselnde verwenden aller 3 stimmen kann man das ganze dann quasi strecken, so das man 8bit bei ca 11khz bekommt. (der 11 khz player sollte daher einen deutlich weniger starken einbruch bei 8khz haben). wenn man jetzt wie bei dem 44khz player die samplefrequenz weiter erhöht können die counter im sid nie ihren maximalwert erreichen, womit die tatsächlich erzielbare auflösung abnimmt und das ganze leiser wird. das aliasing entsteht aus ähnlichen gründen... tatsächlich wird ja nicht für jedes sample der entsprechende pegel am ausgang eingestellt (so wie man klassischerweise ein sample abspielt), sondern es wird der oszillator so eingestellt das der gewünschte pegel bis zum nächsten sample erreicht ist - und wenn dieses nun schneller geschieht als der oszillator zählen kann gibts eben aliasing