Hallo Ihr schlauen Köpfe, ich habe mal wieder eine Frage an Euch. Ich bin gerade dabei, einen Audio-Recorder für Mono zu entwickeln. Die Qualität der Aufnahme sollte im Bereich mp3 liegen. Das Problem an der Sache ist allerdings, dass zunächst ein Signal aufgenommen, und in einem beliebigen Dateiformat in einem SD-RAM gespeichert werden soll. Mp3 wäre aufgrund der geringen Datenmenge und der schon abgelaufenen Schutzrechte interessant allerdings könnte es ein Problem aufgrund der nächsten beiden Funktionen des Gerätes geben. Denn: 1.) Um Speicher einzusparen soll das Gerät zyklisch aufnehmen, wie bspw. eine Überwachungskamera. 2.) Auf Knopfdruck soll währenddessen, und ohne die Aufnahme zu stoppen, von der gespeicherten Audio-Datei an einem beliebigen Einstiegspunkt ein Sample von einer bis mehrere Minuten herausgeschnitten und als eigene Datei abgespeichert werden. Die Originaldatei soll ebenfalls erhalten bleiben. Das ganze soll von dem Gerät selbst verwaltet werden können. Und zu guter Letzt, das ganze soll portabel sein und die Größe von etwa einem handelsüblichen Diktiergerät nicht überschreiten. Die eingesetzten Komponenten sollten insgesamt auch nicht teurer als 10-15€ werden (bei entsprechender Stückzahl). 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?? Schwebt jemandem von Euch ein brauchbarer Lösungsansatz vor. Bisher hab ich mit einem VLSI-Modul experimentiert, doch dieses Modul neigte dazu, bei kleineren Fehlern komplett abzukacken, sodass ich es hinterher fast nicht mehr aufgesetzt bekommen hab. Außerdem ist mir das Modul zu kompliziert und der Funktionsumfang eines VLSI-Chips mit eigenem Betriebssystem viel zu sehr Overkill. Ich hoffe ihr könnt mir weiterhelfen, im Moment bin ich mit meinem Latein leider am Ende. LG Christian
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
Ich hab den Ausgangspost gelesen und spontan an eine billige Dashcam gedacht. Kamera kann man ja zukleben. ;) mfg mf
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?
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.
Christian schrieb: > Nein, wenn er voll ist, werden die Daten zyklisch überschrieben. Oben hattest du noch geschrieben, dass du das auch abspeichern willst: Christian schrieb: > Die Originaldatei soll ebenfalls erhalten bleiben. Christian schrieb: > 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? Nein. In dem Fall muss er die Daten ja nur von a nach b schieben. >> Und fuer unkomprimierte Daten zu wenig RAM... > > auch bei externem RAM? Man kann natürlich einen großen RAM anschließen. Aber das wird sich halt auch kostenmäßig auswirken.
:
Bearbeitet durch User
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?
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
●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.
Christian schrieb: > Jetzt muss ich nur noch recherchieren, wie man aus zigtausend Frames > eine mp3 Datei zusammenschustert. Einfach, indem man sie hintereinander hängt. Bedenke, dass mp3 ein Streaming-Format ist und man daher einfach an jedem beliebigen Frame beginnen kann.
:
Bearbeitet durch User
Christian schrieb: > Erstens kann ich dort bestimmt nicht ohne weiteres in die Firm > eingreifen, um die konkreten Funktionen zu implementieren, um welche es > zwingend geht. Christian schrieb: > Um Speicher einzusparen soll das Gerät zyklisch aufnehmen, Check Christian schrieb: > Auf Knopfdruck soll währenddessen, und ohne die Aufnahme zu stoppen, von > der gespeicherten Audio-Datei an einem beliebigen Einstiegspunkt ein > Sample von einer bis mehrere Minuten herausgeschnitten und als eigene > Datei abgespeichert werden. Die Originaldatei soll ebenfalls erhalten > bleiben. Check Christian schrieb: > das ganze soll portabel sein und die Größe von etwa einem > handelsüblichen Diktiergerät nicht überschreiten Check Christian schrieb: > Zweitens lässt sich sowas nicht in Serie umsetzen. Dashcams sind in Serie: Check Ü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? mfg mf
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
Christian schrieb: > Also ich hab jetzt mit einer mp3 Datei herumexperimentiert 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
Achim M. schrieb: > * Den Dynamikumfang kann man auch akustisch komprimieren, was bei > Sprache auch nicht viel ausmacht bzw. sowieso gemacht werden mus Man kann es ja auch nichtlinear speichern, wie es z.B. auch bei ISDN gemacht wurde. Dann hat man nicht so viel Quantisierungsrauschen, und es hört sich deutlich besser an als 8 Bit linear. Siehe https://de.wikipedia.org/wiki/A-law
> Ü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!!
Hi Chris, Bin durch Zufall auf den Thread gestoßen (Hab mich schlicht verklickt) Nun aber schon mal Gelesen: Wenn du sogenannte Ringloop Audioafzeichnung machen willst, dan ist folgendes von Vorteil: Als Speicher ein FRAM nehmen, da praktisch beliebig oft überschreitbar. Löschen ist nicht nötig, das wird sowieso erledigt. Kein BackupRAM nötig, der Speicher ist Permanent, auch ohne Stromversorgung. Schreib/Lese-Cycle braucht weniger Strom als ein Flash. Ist auch noch schneller wie ein Flash. Je nach dem was du aufzeichnen willst (Sprache?/Musik?/Qualität?) muss nicht zwingend MP3 Verwendet werden. Ich habe solche Sachen schon für Überwachungssysteme gebaut. Dies einfach mal als Grundidee.
Christian schrieb: > So, das war's jetzt aber auch schon wieder, was ich zu dem von Dir > angeschnittenen Thema loswerden musste. Gut, dass das geklärt ist. Rolf M. schrieb: > Achim M. schrieb: > >> Den Dynamikumfang kann man auch akustisch komprimieren, was bei >> Sprache auch nicht viel ausmacht bzw. sowieso gemacht werden mus > > Man kann es ja auch nichtlinear speichern, wie es z.B. auch bei ISDN > gemacht wurde. Dann hat man nicht so viel Quantisierungsrauschen, und es > hört sich deutlich besser an als 8 Bit linear. > Siehe https://de.wikipedia.org/wiki/A-law Das wäre doch ein Ansatz; die waves lassen sich damit immer noch byteweise ohne Verluste schneiden. Wobei ich jetzt angenommen hatte, dass es primär Sprache ist, die aufgenommen werden soll. Was genau mit mp3-Qualität gemeint ist? Soll es evtl. doch das ganze oder leicht eingeschränkte hörbare Audiofrequenzband sein? A-law kann dir ein kleiner Cortex-M schon Echtzeit-fähig bereitstellen, dank USB-Interface kann praktischerweise auch gleich auf einem USB-Stick gespeichert werden. Die von den Herstellern angebotenen Applikationsbeispiele sind außerdem frei, sodass man sich nicht mit Lizenzkosten herumschlagen muss. 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. Die Erfindungshöhe ist wohl gering, sowas digital realisieren zu wollen. mfg mf
:
Bearbeitet durch User
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"
Rolf M. schrieb: > Man kann es ja auch nichtlinear speichern, wie es z.B. auch bei ISDN > gemacht wurde. Dann hat man nicht so viel Quantisierungsrauschen, und es > hört sich deutlich besser an als 8 Bit linear. G.711 ist zur Zeit noch, allgemein akzeptierter Standard in Deutschland (a-law). Andere (G.722, Opus) nur optional.
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.
c-hater schrieb: > 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)... Das Problem ist, dass man SD-Karten ihre Langlebigkeit nicht ansehen kann. Und die Qualität kann schwanken. Du weißt also nicht, wie lange sie durchhält. >> 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. Deutlich einfacher wäre sicherlich ein RAM mit QSPI-Port. Das wird heute auch von einigen µCs unterstützt, und man brauch nicht gleich so viele Pins und die ganze Refresherei.
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: > 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. Ja das ist richtig, dann reicht schon ein sehr einfacher Mikrocontroller. Entweder externer MP3 oder eben A-LAW Codieren und erst auf dem Host in MP3 wandeln. Ich habe zu diesem zweck ein Eigenes Komprimier-verfahren entwickelt, das Verlustfrei komprimiert, und trotzdem sehr platzsparend ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.