Mono Audiorecorder

Christian schrieb:
> Ich hoffe ihr könnt mir weiterhelfen

Mit einem Design, welches bei kleineren Fehlern nicht abkackt ?

Nein.

Mach halt keine derartigen Fehler. Der VLSI Chip ist schon ok dafür. Du 
willst einen Audiokompressoralgorithmus nicht selber in einen uC 
schreiben.


Es reicht die Blockkopieraktionen zu schreiben.

Die frühen digitalen audiorekorder hatten einen 1MBit RAM und 1-bit A/D 
bzw. D/A. Dazu einen Zähler und eine refresh Logik. War sehr simpel, 
paßte vor ~25 Jahren schon in eine Streichholzschachtel.

Christian schrieb:

> 1.) Um Speicher einzusparen soll das Gerät zyklisch aufnehmen, wie bspw.
> eine Überwachungskamera.

Kein Problem. Mit der entsprechenden Konfiguration des Kompressors (CBR) 
entstehen Frames konstanter Größe.

> 2.) Auf Knopfdruck soll währenddessen, und ohne die Aufnahme zu stoppen,
> von der gespeicherten Audio-Datei an einem beliebigen Einstiegspunkt

Naja, ganz beliebig kann er natürlich nicht sein. Muß natürlich an einer 
Framegrenze liegen.

> Wie sieht es überhaupt mit der Manipulation an mp3 Dateien aus?? Einfach
> so wie bei einer wave Samples rauszwacken und dann abspielen is hier
> nicht, oder??

Einzelne Samples nicht. Aber Frames schon. Bei CBR ist das easy, weil 
die dann alle gleich groß sind.

> Schwebt jemandem von Euch ein brauchbarer Lösungsansatz vor.

Für dich? Ja: lerne was über die Formate, mit denen du hantierst!

MaWin schrieb:
> Mit einem Design, welches bei kleineren Fehlern nicht abkackt ?

Das Design war leider noch garnicht das Problem, zum Experimentieren 
wurde mit einem fertigen Modul gearbeitet. Viel mehr haperte es an der 
Programmierung. Es war mir schlicht zu kompliziert. Mittlerweile lässt 
sich das Modul nicht mehr booten und auch das Aufspielen der Firmware 
klappt nicht mehr so wie es in diversen Foren erklärt wird. Das Modul 
wurde pfleglich behandelt, es hat also bestimmt keinen Hardwareschaden.

Da ich mich bei diesem Modul letztendlich nicht mehr rausgesehen hab, 
ging ich nun den Weg, das ganze auf einem STM32 zu realisieren. Anstatt 
mp3s zu manipulieren würde ich direkt mit den Rohaudiodateien arbeiten. 
Als zyklischer Speicher würde ich mich mit einem RAM mit etwas über 10 
Minuten (128Mb) Speicherkapazität begnügen. Die jeweiligen Samples 
sollen dann auf einem Flash abgelegt werden. Die Konvertierung der 
gespeicherten Samples im Raw-Format soll dann meinetwegen extern 
erfolgen. Allerdings befürchte ich, dass dieser Lösungsansatz das Budget 
sprengen wird.

Gäbe es hier eigentlich jemanden, der mit dem VLSI-Chip Erfahrung hat?
Womöglich sind es ja nur Kleinigkeiten, die mich zu Fall gebracht haben.

Christian schrieb:
> Die Qualität der Aufnahme sollte im Bereich mp3 liegen.

Das kann beliebig gut oder schlecht bedeuten. Welche Bitrate?

Stefan ⛄ F. schrieb:
> Christian schrieb:
>> Die Qualität der Aufnahme sollte im Bereich mp3 liegen.
>
> Das kann beliebig gut oder schlecht bedeuten. Welche Bitrate?

128kbps wären schon völlig ausreichend.

> mit einem RAM mit etwas über 10
> Minuten (128Mb) Speicherkapazität begnügen

SCNR.

Trotzdem mal ein Tip: Ein Feld, Wald und Wiesen-STM32 hat
fuer Audioverarbeitung auf komprimierten Audiodaten zu wenig
Bumms. Und fuer unkomprimierte Daten zu wenig RAM...

Es gibt den Baustein VLSI VS1053 mit integriertem MP3 codec. Low cost 
gibts die Winbond ISD1700 Serie mit SPI. Und hier sind ein paar 
interessante Miniprojekte http://www.moty22.co.uk/sd.php

foobaz schrieb:

> Trotzdem mal ein Tip: Ein Feld, Wald und Wiesen-STM32 hat
> fuer Audioverarbeitung auf komprimierten Audiodaten zu wenig
> Bumms.

gilt das auch dafür wenn die Daten bereits in mp3 daherkommen?

> Und fuer unkomprimierte Daten zu wenig RAM...

auch bei externem RAM?

Das Teil sieht schon recht vielversprechend aus, obwohl die SD-Karte in 
dem Fall später durch einen fest installierten Speicher ersetzt werden 
müsste.

Für den Anwender abrufbar gespeichert dürfen letztendlich nur die 
erstellten Blöcke sein.

Rolf M. schrieb:
> Christian schrieb:
>> Als zyklischer Speicher würde ich mich mit einem RAM mit etwas über 10
>> Minuten (128Mb) Speicherkapazität begnügen.
>
> Und wenn der voll ist, schreibst du das alles am Stück in einen Flash?

Nein, wenn er voll ist, werden die Daten zyklisch überschrieben.
Daraus ergibt sich dass z.B. die letzten 10 Minuten immer gespeichert 
sind, ist darin ein Block enthalten, den ich benötige, muss dieser Block 
rechtzeitig in einen Flash kopiert werden, bevor er wieder überschrieben 
wird.

Rolf M. schrieb:
> Oben hattest du noch geschrieben, dass du das auch abspeichern willst:

Mein Fehler, ein Abspeichern über die Zykluszeit hinaus ist nicht 
notwendig.

Der Ansatz wäre also ein zuverlässiger Codec-Konverter, einen RAM, einen 
Flash und einen µC der sich um die Speicherlogistik kümmert?

●DesIntegrator ●. schrieb:
> Achim M. schrieb:
>
>> Ich hab den Ausgangspost gelesen und spontan an eine billige Dashcam
>> gedacht. Kamera kann man ja zukleben. ;)
>
> und zum Speicher-Sparen die geringst mögliche Videoauflösung wählen

Aus dem Ansatz wird aus mehreren Gründen nix.

Erstens kann ich dort bestimmt nicht ohne weiteres in die Firm 
eingreifen, um die konkreten Funktionen zu implementieren, um welche es 
zwingend geht.

Zweitens lässt sich sowas nicht in Serie umsetzen.

Aber für ne Bastelei wär‘s ne Möglichkeit.

Michaela M. schrieb:
> https://www.thomann.de/intl/zoom_h1n.htm

Daran dachte ich auch als erstes. Der kann mit einer 32GByte-SD-Karte 
rund 70h MP3 mit 128kBit/s aufnehmen. Allerdings ist die Karte dann voll 
und muss gelöscht werden - also kein Dauerbetrieb mit automatischem 
Löschen der ältesten Aufnahme. Deshalb habe ich es vermieden, darauf 
hinzuweisen.

Die Lösung mit dem zyklischen Überschreiben erfordert zumindest den 
Speicherplatz von zwei Files. Ich kann mir nicht vorstellen, dass ein 
auf dem Ringpuffer basierender Ansatz mit einem File auskommt.

HildeK schrieb:
> Die Lösung mit dem zyklischen Überschreiben erfordert zumindest den
> Speicherplatz von zwei Files. Ich kann mir nicht vorstellen, dass ein
> auf dem Ringpuffer basierender Ansatz mit einem File auskommt.

Das verstehe ich nun nicht nicht ganz.

Also ich hab es mir zumindest so vorgestellt:

Als zyklischer Speicher kommt nur ein RAM in Frage, alles andere wäre 
für den Dauerbetrieb nicht ausgelegt, da die alle recht bald hinüber 
wären. Eine Zyklusdauer von 10 Minuten wäre für mein Verständnis schon 
vollkommen ausreichend. Je nach Format (komprimiert, oder unkomprimiert) 
sollte dieser eben 10MB oder 100MB haben.

(Obwohl die größere Variante für mich eher nicht in Frage kommt, da 
damit leider alles größer wird -> Das Produkt, der Routingaufwand, der 
Fertigungsaufwand und vor allem der Preis.)

Wenn ich nun im laufenden Betrieb dem Controller mitteile, dass er einen 
Block wegspeichern soll, z.B. von vor 5 Minuten bis jetzt, dann muss 
dieser die Startadresse des aktuellen mp3-Frames erfassen, und von 
diesem soweit zurückrechnen, bis eine Gesamtdauer von 5 Minuten minus 
dem aktuellen Frame erreicht wird. Dann soll der gesamte Speicherinhalt 
von dem errechneten Startframe bis zum Ende des Frames in welchem sich 
die Aufnahme zum Zeitpunkt des Request befand, als eine mp3 File in den 
Flash-Speicher kopiert werden.

Hab ich das so richtig interpretiert?

Das Gerät dient ausschließlich dem dauernden Zuhören und dem Abspeichern 
von 10-20 kurzen Blöcken mit maximal je 5 Minuten Dauer. Eine 
Weiterbearbeitung der gespeicherten Blöcke erfolgt später am PC.
Dafür gibt's reichlich Software.

Christian schrieb:
> HildeK schrieb:
>> Die Lösung mit dem zyklischen Überschreiben erfordert zumindest den
>> Speicherplatz von zwei Files. Ich kann mir nicht vorstellen, dass ein
>> auf dem Ringpuffer basierender Ansatz mit einem File auskommt.
>
> Das verstehe ich nun nicht nicht ganz.

Ok, oder ich verstehe es nicht.
Zumindest haben meine weiteren Recherchen gezeigt, dass die einzelnen 
Frames offenbar einzeln und unabhängig vom Rest verarbeitbar sind und 
damit auch als Startpunkt gewählt werden könnten. Damit müsste deine 
Idee dann doch so funktionieren; man muss nur jeweils den Header eines 
Frames finden.
Einen Hinweis dazu fand ich hier, wenn auch schon älter, vom User 
'Gausi': 
https://entwickler-ecke.de/topic_MP3++Aufbau+Header+Laenge+_47898,0.html

HildeK schrieb:
man muss nur jeweils den Header eines
> Frames finden.

11 Einsen hintereinander bei vorgegebenem Takt sollten recht einfach 
lokalisierbar sein.

Jetzt muss ich nur noch recherchieren, wie man aus zigtausend Frames 
eine mp3 Datei zusammenschustert.

Also ich hab jetzt mit einer mp3 Datei herumexperimentiert und einfach 
schildbürgermäßig vom Anfang weg, also mitsamt ID3v2 und allem was da 
vorne so als Header drin sein könnte, bis etwa zur Mitte einfach 
gelöscht.

Die Datei war anschließend tatsächlich spielbar. Mir ist allerding 
sofort aufgefallen, dass der Rest, den ich nicht weggelöscht habe 
während dem Abspielen seltsam blubberte, als ob man das Stück, abgesehen 
von der gleichbleibenden Tonqualität, in einer Badewanne anhören würde, 
in welche es währenddessen vom Wasserhanhn reintropft.

Hat von Euch jemand eine Ahnung, woran das liegen könnte?? es dürften 
doch nicht mehr als 9 Frames sein, die voneinander abhänging sein 
können, stattdessen blubbert das ganze restliche Lied.

Christian schrieb:
> Hat von Euch jemand eine Ahnung, woran das liegen könnte??

Klingt nach einem Bug in deinem MP3 Player. Ich kann dein Problem mit 
"mpg123" und "vlc" unter Linux nicht nachvollziehen.

http://www.mp3-tech.org/programmer/frame_header.html

> Übrigens, für eine Serienentwicklung wäre es doch schön, dem Forum 20%
> der Entwicklungsumlage abzudrucken. Oder in anderen Worten, sollen wir
> das jetzt mit entwickeln?

Ehrlich gesagt, wenn sich sämtliche Anforderungen dadurch nachhaltig 
erfüllen lassen spricht nichts dagegen, allerdings ... Soll mir Dein 
Vorschlag einfach ne Dashcam umzumurksen und das mal ein paar 1.000 
tatsächlich weiterhelfen??

Bitte versteh mich nicht falsch, ich halte Deinen Vorschlag ja 
keineswegs für schlecht, er ist nur leider für diesen Fall 
unpraktikabel. Ich muss verständlicherweise einige wichtige 
Informationen aus Gründen der notwendigen Geheimhaltung zurückbehalten 
und einige davon sind tatsächlich auch ein Ausschlusskriterium für 
Deinen Vorschlag.

Wer übrigens interessiert ist und es sich zutraut, kann sich 
selbstverständlich damit was dazuverdienen - und bevor jemand auf 
falsche Gedanken kommt ... NICHT SCHATTENWIRTSCHAFTLICH!!!
Nebenbei sei erwähnt, wir hätten Arbeit genug und nix dagegen 
einzuwenden wenn uns jemand dauerhaft unterstützen möchte.

So, das war's jetzt aber auch schon wieder, was ich zu dem von Dir 
angeschnittenen Thema loswerden musste.

LG
Chris

Achim M. schrieb:
> Muss es denn zwingend MP3 sein?

Ja, zumindest das Endprodukt muss zwingend mp3 sein. Mag sein, dass ich 
es mir nur einbilde aber ich denke, dass sich die Speichverwaltung der 
Wave-Dateien, auch hinsichtlich der späteren Übertragung vom Flash zur 
Endbestimmung und für diese selbst aufwändiger gestaltet.

Achim M. schrieb:

> Muss es denn zwingend MP3 sein?
> Für Sprache, gemeinhin 300Hz...3,5kHz tut es auch 8bit Mono mit 8kHz,
> was dann 64kbps ergibt. Vorteile:
>
> * Die musst du nicht groß encodieren
> * Den Dynamikumfang kann man auch akustisch komprimieren, was bei
> Sprache auch nicht viel ausmacht bzw. sowieso gemacht werden muss
> * Die 8bits sind genau 1 Sample, du kannst also an beliebiger Stelle
> schneiden und für den Read-Only protected Speicher einfach einen
> passenden .wav-Header davorknallen.
>
> mfg mf

Auch ein sehr guter Vorschlag!!

Patrick L. schrieb:
> Als Speicher ein FRAM nehmen...

Hab ich mir auch schon überlegt, aber bei all den Vorteilen die ein FRAM 
hat, gibt es auch einen ordentlichen Nachteil ... der Preis. Soweit ich 
weiß, waren die ja schon vor Corona richtig teuer :(

HildeK schrieb:

> Die Lösung mit dem zyklischen Überschreiben erfordert zumindest den
> Speicherplatz von zwei Files. Ich kann mir nicht vorstellen, dass ein
> auf dem Ringpuffer basierender Ansatz mit einem File auskommt.

Wieso? Ich sehe nix, was dagegen spricht.

Ein File maximaler Länge zu erzeugen ist ein einmaliger Vorgang. Danach 
sind keinerlei Verwaltungsinformationen mehr zu schreiben, sondern nur 
noch Inhalts-"Sektoren". Deren Größe wählt man sinnvollerweise 
entsprechend der nativen Größe der Blöcke der SD-Karte.

Man muß nun nur noch genügend RAM-Puffer haben, um die gelegentlichen 
Schluckaufs der SD-Karte durch das wear-leveling zu überbrücken.

Da es hier um MP3 geht und die Bitrate ziemlich gering (und 
sinnvollerweise konstant) ist, sehe ich da kein Problem. Schon mit dem 
RAM eines Mega1284P oder AVRxxxDA/Byyyy schafft man es bei 128kBit/s ca. 
eine Sekunde zu puffern. Das sollte für schnelle SD-Karten vollkommen 
ausreichen.

Man sollte sich in's Gedächtnis rufen, dass diese Dinger in der Lage 
sein sollen, kontinuierlich HD-Videoströme aufzuzeichnen. Also Sachen 
mit wesentlich höherer Bitrate als die lächerlichen 128kBit/s, um die es 
hier geht.

Achim M. schrieb:
> Das wäre doch ein Ansatz;

Auf jeden Fall!
Aufgenommen werden vorwiegend Sprache und Geräusche via Elektret oder 
MEMS.
Es kommt auch bestimmt kein Oberwellenfanatismus zu tragen.

Achim M. schrieb:
> Dass ein Audio-Ringspeicher mit herausschneidbaren Sequenzen irgendwie
> (patent-)rechtlich geschützt sein soll, kann nicht sein. Schließlich war
> das alles mit Endlosband und setzen von Markern auf einer zweiten Spur
> schon zu Magnetbandzeiten populär.

Das gab's sogar schon vorher, als man noch auf Draht speicherte ... :)
Diese Patentrechte sind schon längst abgelaufen

> Die Erfindungshöhe ist wohl gering,
> sowas digital realisieren zu wollen.

Ja, viel zu gering.

Tja wenn's patentfähig wäre, hätten wir es schon. Leider ist der 
spezielle Anwendungsfall gerade deshalb tunlichst geheim zu halten um 
unseren Marktvorteil nicht zu verhauen.

c-hater schrieb:

> Ein File maximaler Länge zu erzeugen ist ein einmaliger Vorgang. Danach
> sind keinerlei Verwaltungsinformationen mehr zu schreiben, sondern nur
> noch Inhalts-"Sektoren". Deren Größe wählt man sinnvollerweise
> entsprechend der nativen Größe der Blöcke der SD-Karte.
>
> Man muß nun nur noch genügend RAM-Puffer haben, um die gelegentlichen
> Schluckaufs der SD-Karte durch das wear-leveling zu überbrücken.
>
> Da es hier um MP3 geht und die Bitrate ziemlich gering (und
> sinnvollerweise konstant) ist, sehe ich da kein Problem. Schon mit dem
> RAM eines Mega1284P oder AVRxxxDA/Byyyy schafft man es bei 128kBit/s ca.
> eine Sekunde zu puffern. Das sollte für schnelle SD-Karten vollkommen
> ausreichen.
>
> Man sollte sich in's Gedächtnis rufen, dass diese Dinger in der Lage
> sein sollen, kontinuierlich HD-Videoströme aufzuzeichnen. Also Sachen
> mit wesentlich höherer Bitrate als die lächerlichen 128kBit/s, um die es
> hier geht.

Würde denn eine SD-Karte für den Ringbuffer lange genug halten. Das Teil 
soll 24/7 aufnehmen und naja, eigentlich "nie" kaputt gehen.
Aber mal abgesehen davon, dafür und auch auch um die Blöcke 
abzuspeichern soll keine SD-Karte verwendet werden, um nicht ohne 
weiteres an die gespeicherten Blöcke oder die aktuelle Aufnahme zu 
kommen.

Perfekt wäre ein möglichst kleiner µC mit einem SD-RAM-Port, bzw. 
abhängig vom Preis gerne auch ein FRAM, dann noch sicherheitshalber I2C, 
I2S und SPI. aber mit SD-RAM-Port gibt's schon mal nix "kleines"

Einfach ne SD nehmen welche so groß ist, dass die Zyklen derart lange 
werden und sich dadurch etliche Jahre Haltbarkeit ausgehen geht übrigens 
auf keinen Fall. Das Teil würde schlicht alles aufnehmen was daneben 
gesprochen wird und für sehr lange Zeit behalten. Damit ließe sich das 
Gerät zum Auspionieren und Abhören missbrauchen und das muss jedenfalls 
vermieden werden - alleine schon wegen dem Recht auf Privatspähre und 
vom Imageschaden des Herstellers ganz zu schweigen.

Christian schrieb:
> Perfekt wäre ein möglichst kleiner µC mit einem SD-RAM-Port, bzw.
> abhängig vom Preis gerne auch ein FRAM, dann noch sicherheitshalber I2C,
> I2S und SPI. aber mit SD-RAM-Port gibt's schon mal nix "kleines"

überlesen? Beitrag "Re: Mono Audiorecorder"

Helge schrieb:

> überlesen? Beitrag "Re: Mono Audiorecorder"

Nein hab ich nicht, ich werde auf alle Fälle damit experimentieren. 
Hatte aber noch zu wenig Zeit, um mich umfangreich in die Datenblätrter 
einzulesen.

Christian schrieb:

> Würde denn eine SD-Karte für den Ringbuffer lange genug halten. Das Teil
> soll 24/7 aufnehmen und naja, eigentlich "nie" kaputt gehen.

Das wird auf keinen Fall möglich sein. Nix ist für die Ewigkeit, 
insbesondere nicht Flash als Speichermedium.

Trotzdem benutzt heutzutage jeder SSDs als Massenspeicher, welche ja 
ebenfalls letztlich auf der Flash-Technologie basieren.

Was man aber ziemlich sicher sagen kann, ist: die beschriebene Art der 
Nutzung des Flash garantiert die maximale Betriebsdauer für die 
SD-Karte. Ob die für deine Anwendung dann ausreichend ist, hängt im 
Wesentlichen nur von drei Faktoren ab: Größe der SD-Karte und deren 
Qualität und deinem Anspruch an die Lebensdauer.

Das Blöde ist eigentlich nur: auch der Preis der SD-Karten hängt exakt 
auf dieselbe Weise von diesen beiden ersten Faktoren ab (überteuerte 
Fakes seien hier mal außen vor)...

> Perfekt wäre ein möglichst kleiner µC mit einem SD-RAM-Port

Kannst du mit einem RaspiPico (RP2040) haben. Die PIOs machen es 
möglich. Allerdings brauchst du dafür ältere SD-RAMs. Die topmodernen 
sind einfach zu vergesslich. Zum Glück sind ältere SDRAMs noch recht gut 
verfügbar. Aber leider mit steigender Tendenz bei den Preisen. Wirklich 
günstig ist hier zu jedem beliebigen Zeitpunkt immer nur die jeweils 
vorletzte Generation.

Christian schrieb:
> 11 Einsen hintereinander bei vorgegebenem Takt sollten recht einfach
> lokalisierbar sein.

Ich habe gerade mal willkürlich aus einem bestehenden MP3-File einen 
Block herausgeschnitten, ohne auf den Headerbeginn zu achten.
Diverse MP3 Tools (Audacity, WinAmp, MP3DirectCut) haben kein Problem 
damit, den abzuspielen. Man muss also gar nicht zwingend den richtigen 
Headerbeginn finden, zudem fand ich im File mehrere Stellen, die 0xFF 
z.B. zwei-, drei- oder viermal hintereinander hatten. Da wird es 
schwierig, 11 Einsen sicher zu finden.

Man muss also nur etwas mehr als die maximale Aufzeichnungszeit in einen 
Ringpuffer nehmen ([F]RAM). Für 10 Minuten @128kbit/s also z.B. rund 
10MB in einem Ringpuffer speichern und diesen auf Tastendruck komplett 
in ein Flash oder EEPROM wegkopieren. Ich kann jetzt nicht abschätzen, 
wie viel Zeit das in Anspruch nimmt, so dass man ggf. den Ringpuffer 
größer vorhalten müsste.

Für 10 Minuten Samples werden bei 8 Bit und 8k Samples/Sekunde 4,8 MByte 
benötigt (600 Sekunden * 8k Samples).

Wie wäre es mit einem ESP32, den gibt es als "Wrover" Modul mit 4 oder 8 
MByte PSRAM und er dürfte preislich hinkommen. Schnell genug ist er 
auch, zumindest wenn man auf MP3 verzichtet. WLAN oder Bluetooth musst 
Du nicht nutzen, dann benötigt er weniger Strom.

Die Wrover bekommst Du fertig als Arduino kompatibles Board in 
unterschiedlichen Ausführungen, teilweise mit SD-Slot. Das lässt sich 
gut als preiswertes Devboard nutzen.

Die MP3-Wandlung kann dann ggf. am PC erfolgen.

nochneIdee schrieb:
> Für 10 Minuten Samples werden bei 8 Bit und 8k Samples/Sekunde 4,8
> MByte benötigt (600 Sekunden * 8k Samples).
> Wie wäre es mit einem ESP32, den gibt es als "Wrover" Modul mit 4 oder 8
> MByte PSRAM und er dürfte preislich hinkommen. Schnell genug ist er
> auch, zumindest wenn man auf MP3 verzichtet. WLAN oder Bluetooth musst
> Du nicht nutzen, dann benötigt er weniger Strom.
> Die Wrover bekommst Du fertig als Arduino kompatibles Board in
> unterschiedlichen Ausführungen, teilweise mit SD-Slot. Das lässt sich
> gut als preiswertes Devboard nutzen.
> Die MP3-Wandlung kann dann ggf. am PC erfolgen.

Das klingt auch sehr interessant, vor allem wegen des internen RAM. Wenn 
aber die Aufnahmequalität nicht reicht, müsste ich gleich von Anfang an 
mit mp3s arbeiten.
Würde ich da nen mp3 Codec Konverter, also z.B. den VS1053 für den mp3 
Stream nehmen ginge das doch auch. Schließlich wäre der ESP doch nur zum 
Konvertieren zu langsam, verwalten schafft der das spielend. Damit käme 
ich doch schon nahe ans Endprodukt ran.

Christian schrieb:
> wegen des internen RAM

Ich meinte modulintern