Henry Kiefer wrote: > [Audio kodieren]
Dann guck' dir mal ADPCM an. Sollte auch auf kleineren Microcontrollern in Echtzeit zu kodieren sein, und liefert ganz anständige Ergebnisse.
Kannst ja mal experimentieren, der Codec gehört fest zu Windows (der Audiorekorder kann z.B. in dem Format speichern). 44kHz/16Bit runtergerechnet auf 4 Bit ADPCM hört man z.B. kaum, was ich für 25% Dateilänge doch recht erstaunlich finde.
-- thomas.kindler@gmx.de, www.bredobrothers.de www.microsoft-hellhounds.de
Telefonqualität: PCM-Codec über SPI an Controller. 64kBit/sec. Rauschiger wäre CVSD: 16-32kBit/sec. Aber interner 10 Bit A/D-Wandler des Controllers bzw. als D/A R2R-Netztwerk an Ports verwendbar. Wurde unlängst in dieser newsgroup unter "Anti-Aliasing Tiefpass" vgl groups google durchgekaut.
Für ADPCM gäbe es ApplicationNote von Microchip. Würde sich eignen um PCM-Codec von 64kBit auf 32kBit zu schrumpfen. Qualitätsverlust muß nicht groß sein, vgl. DECT-Telefone, aber dann eventuell auf 8 Bit Controller mühsam.
Jedoch: in der Qualität/Bandbreite ist das alles von "mp3 Encoder/Decoder-Chip" etwas entfernt.
MfG JRD
"Georg Acher" schrieb im Newsbeitrag news:eqpuja$oiq$ snipped-for-privacy@news.lrz-muenchen.de... | "Henry Kiefer" writes: | >"Georg Acher" schrieb im Newsbeitrag news:eqpptg$lgt$ snipped-for-privacy@news.lrz-muenchen.de... | >| Die SW/HW zu den DAB-Portables ist überwiegend in GB entwickelt worden | >| (Radioscape, Frontier Silicon, Enigma Technologies). Bei Radioscape-SW steckt | >| eigentlich immer ein TI-DSP dahinter, selbst wenn aussen ein koreanisches | >| Perstel-Logo klebt... | >
| >Na schön. Ich redete von mp3, jetzt sind wir bei DAB. Das kann ich echt nicht | >brauchen. Wollte nix senden. | | Ich bezog mich auch auf die Auslagerung nach Indien ;-)
Eventuell basteln sie gerade an DAB einen Block weiter neben dir, oder mir. Wer weiß das schon.
- Henry
--
"Rafael Deliano" schrieb im Newsbeitrag news: snipped-for-privacy@t-online.de... | >> Mono mit Telefonqualität würde mir reichen. | > Dann guck' dir mal ADPCM an. Sollte auch auf kleineren Microcontrollern | > in Echtzeit zu kodieren sein, und liefert ganz anständige Ergebnisse. | | Telefonqualität: PCM-Codec über SPI an Controller. 64kBit/sec. | Rauschiger wäre CVSD: 16-32kBit/sec. Aber interner 10 Bit A/D-Wandler | des Controllers bzw. als D/A R2R-Netztwerk an Ports verwendbar. | Wurde unlängst in dieser newsgroup unter "Anti-Aliasing Tiefpass" | vgl groups google durchgekaut.
Werde ich mir mal den Thread ansehen. Irgendwelche Vorschläge fürs Codec? Soweit ich mich erinnere, waren das immer so Abkündigungskandidaten. Ideal wäre natürlich eines, was intern schon etwas komprimiert.
| | Für ADPCM gäbe es ApplicationNote von Microchip. | Würde sich eignen um PCM-Codec von 64kBit auf 32kBit zu schrumpfen. | Qualitätsverlust muß nicht groß sein, vgl. DECT-Telefone, aber | dann eventuell auf 8 Bit Controller mühsam.
Schon vorher gesichtet und mal kurz überflogen. Liegt jetzt unter "interessant".
| | Jedoch: in der Qualität/Bandbreite ist das alles von | "mp3 Encoder/Decoder-Chip" etwas entfernt.
Das ist ja das verwunderliche - es gibt anscheinend nichts. Wie lange laufen eigentlich noch die Ansprüche von Fraunhofer?
- Henry
--
"Thomas Kindler" schrieb im Newsbeitrag news:eqpvf5$d7n$ snipped-for-privacy@news01.versatel.de... | Henry Kiefer wrote: | > [Audio kodieren] | > Mono mit Telefonqualität würde mir reichen. | | Dann guck' dir mal ADPCM an. Sollte auch auf kleineren Microcontrollern | in Echtzeit zu kodieren sein, und liefert ganz anständige Ergebnisse. | | Kannst ja mal experimentieren, der Codec gehört fest zu Windows (der | Audiorekorder kann z.B. in dem Format speichern). 44kHz/16Bit | runtergerechnet auf 4 Bit ADPCM hört man z.B. kaum, was ich für 25% | Dateilänge doch recht erstaunlich finde.
Wenn ich partout nichts finde, dann läufts auch auf ADPCM raus.
- Henry
--
"Markus" schrieb im Newsbeitrag news:45d07a73$0$30323$ snipped-for-privacy@newsspool1.arcor-online.net... | Ich erklärs nochmal in vier einfachen Schritten: | | A) Absolutes Maximum über die letzten z.B. 512 gesammelten Samples erstellen. | B) 2er-Logaritmus(aller 512 Samplewerte) berechnen. | C) Das Maximum mit voller Bitauflösung speichern. | D) Die 512 Samples mit 3 oder 4 Bit Auflösung abspeichern. | | Für einen Anrufbeantworter reicht das allemal.
Wie kommst du auf den Algorithmus? Ist der irgendwo dokumentiert bzw. kann man sich Samples anhören? Hast du das schon mal umgesetzt?
| | Um das Ganze echzeittauglich auf einem 8-Bit-AVR zum laufen zu bringen | speichert man das Absolutmaximum _nach_ den 512 Samples und benutzt | für die Skalierung das Absolutmaximum der vorangegangenen 512 Samples. | Man kann auch weniger als 512 Samples nehmen und außerdem kann man | wenn man sich das vorige Absolutmaximum merkt noch zusätzlich | einen Korrekturoffset speichern der beim Dekodieren benutzt wird. | | > Eine Lösung OHNE spezielle PC-Software fänd ich persönlich gut. | > Hast du was fertig? | | Nur eingebettet in eine Recordingsoftware, aber der Code lässt sich | wirklich in weniger als 30 Minuten hintippen.
Das finde ich nervig wieder ein extra Programm zu machen. Wenn das Betriebssystem im Prinzip alles notwendige stellt, dann ist das doch Quatsch.
- Henry
--
Die +/-5V CMOS-Oldtimer in DIL aus den 80ern sind genau so "obsolet" wie ein 741er OP. Sie wurden aber in Unmengen produziert und sind deshalb problemlos z.B. via ebay erhältlich:
Insofern werden sie länger verfügbar sein als manches was heute brandneu ist aber keine design ins haben wird.
Für Consumer-ICssollte das kein Problem sein: in jedem Rockwell-Modem-Chip waren ein paar Groschen für Microcom ( MNP10 ) und British Telecom ( V42bis / LZW-BT ).
MfG JRD
Ist da jemand zufällig über ein C/C++-Implementierung gestolpert, idealerweise für TI-DSP-evaluation-boards?!
Mein' ja nur...man kann ja mal fragen :)
brauchen. Wollte nix senden.
Ist aber fast das Gleiche, nur, daß da MP2 verwendet wird :)
Natürlich nicht, ich hätte mich eher gewundert, würde für so ein Nischengerät ein eigener chip entwickelt.
Der DSP ist
wenns full-custom ist, dann wird auch gleich noch der
Yep.
Doch, durchaus...
besser.
Telefonie hat eh nur 8 kHz Samplerate. Da sind die 44 oder gar 48 kHz von MP3 doch hoffnungslos übertrieben.
Wenn also 32 kbps nicht zu viel sind, schau nach ADPCM. Sind halt 4 Bit pro Sample. Als Softwerker kann ich dir allerdings keine fertigen ICs nennen, ich mach sowas eher auf nem Controller :) Das, was Windows als "IMA ADPCM" hat, findest du z.B. im Quelltext von sox in ima_rw.c, und ist auch recht einfach in Assembler zu bauen.
Stefan
news:eqpvf5$d7n$ snipped-for-privacy@news01.versatel.de...
Gibt sogar 'ne Atmel-Appnote (decoder) dazu:
AVR336: ADPCM Decoder
oder auch eine fertige, unkomprimierte Aufnahmelösung:
AVR335: Digital Sound Recorder with AVR® and DataFlash®
Ansonsten ist Telefonqualität ja nicht wirklich schwierig zu erreichen.. bei 11kHz/8bit, und damit 11kB/s kommt man sowieso unkomprimiert hin, auf 64 MByte passen anderthalb Stunden Audio.
Ich würde das mit einer MMC/SD-Karte kombinieren, noch 'nen bisschen FAT-Code dazurühren und fertig ist die Sache. Kann man dann am PC mit Standardsoftware bespielen und aufgenomme Sachen abhören.
-- thomas.kindler@gmx.de, www.bredobrothers.de www.microsoft-hellhounds.de
Deswegen gibt's ja auch noch andere Spielarten von MPEG Audio als nur MPEG1, LayerIII (AKA MP3). Darunter auch einige, die bis 8kHz Samplerate herunterreichen.
Allerdings hat man festgestellt, daß diese Spielarten für MPEG-Audio keinen Sinn machen. Nur für deutlich primitivere Codierungsverfahren bringt eine derartige Reduzierung der Samplerate wirklich etwas bezüglich der Codierungseffizienz und des Rechenzeitbedarfs.
In der FORTH-Zeitschrift wird man vergeblich danach suchen, aber da sind genügend Blockschaltbilder und Erläuterungen für einen Harris-Clone in Software. Die dortige Source des 68HC08 ist bestenfalls 1 A4-Seite, sonst käm die CPU wegen Rechenzeit nicht hin. Auf einem DSP würde sie wegen MAC noch deutlich kürzer. DSP-Varianten zielen typisch auf den Wunsch des Auftraggebers rückwärtskompatibel obsolete Stanag-Varianten im Gerät zu haben, CVSD scheint in Europa beliebt gewesen zu sein. Um die Kompatibiliät damit sicherzustellen dürften aber weitere Tests und Modifikationen nötig sein. Die Stanag-Spec ist glaube ich nicht im www, aber es ist eine Telemetrie-Norm frei verfügbar die sie im Anhang wohl nahezu enthält.
MfG JRD
"Rafael Deliano" schrieb im Newsbeitrag news: snipped-for-privacy@t-online.de... | >> PCM-Codec | > Soweit ich mich erinnere, waren das immer so Abkündigungskandidaten. | Die +/-5V CMOS-Oldtimer in DIL aus den 80ern sind genau so "obsolet" wie | ein 741er OP. Sie wurden aber in Unmengen produziert und sind | deshalb problemlos z.B. via ebay erhältlich: | |
Müßte man die sich auf Lager legen. Sehe schon, da komme ich mit selbstgestickten Codec vermutlich besser weg.
| | Insofern werden sie länger verfügbar sein als manches was heute brandneu | ist aber keine design ins haben wird. | | >> "mp3 Encoder/Decoder-Chip" | > Wie lange laufen eigentlich noch die Ansprüche von Fraunhofer? | Für Consumer-ICssollte das kein Problem sein: in jedem | Rockwell-Modem-Chip | waren ein paar Groschen für Microcom ( MNP10 ) und British Telecom | ( V42bis / LZW-BT ).
Aber für mp3 will offensichtlich keiner zahlen.
- Henry
--
"Thomas Kindler" schrieb im Newsbeitrag news:eqq91c$hl8$ snipped-for-privacy@news01.versatel.de... | Gibt sogar 'ne Atmel-Appnote (decoder) dazu: | | AVR336: ADPCM Decoder |
Hm. Ich mache nix auf AVR. Aber kann ja mal gucken gehn...
| | Ansonsten ist Telefonqualität ja nicht wirklich schwierig zu erreichen.. | bei 11kHz/8bit, und damit 11kB/s kommt man sowieso unkomprimiert hin, | auf 64 MByte passen anderthalb Stunden Audio. | | Ich würde das mit einer MMC/SD-Karte kombinieren, noch 'nen bisschen | FAT-Code dazurühren und fertig ist die Sache. Kann man dann am PC mit | Standardsoftware bespielen und aufgenomme Sachen abhören.
Inwieweit beide Systeme auf die gemeinsame Karte zugreifen können, ist mir aber momenta noch ein Rätsel. Irgendeine Arbitierung und Dirty-Bit muß her.
- Henry
--
"Stefan Reuther" schrieb im Newsbeitrag news: snipped-for-privacy@stefan.msgid.phost.de... | Henry Kiefer wrote: | > "Markus" schrieb... | > | Oder was für Qualitätsansprüche hast du? | >
| > Erstmal für einen Anrufbeantworter. Aber was universelles wäre natürlich besser. | | Telefonie hat eh nur 8 kHz Samplerate. Da sind die 44 oder gar 48 kHz | von MP3 doch hoffnungslos übertrieben. | | Wenn also 32 kbps nicht zu viel sind, schau nach ADPCM. Sind halt 4 Bit | pro Sample. Als Softwerker kann ich dir allerdings keine fertigen ICs | nennen, ich mach sowas eher auf nem Controller :) Das, was Windows als | "IMA ADPCM" hat, findest du z.B. im Quelltext von sox in ima_rw.c, und | ist auch recht einfach in Assembler zu bauen.
mp3 hätte den Vorteil, das ich meine Lösung dann auch für andere angedachte Projekte benutzen kann und nicht wieder von vorne anfang.
Wieviel Rechenleistung brauch dieses ima_rw.c ?
- Henry
--
"Ralph A. Schmid, DK5RAS" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com... | "Henry Kiefer" wrote: | | >Na schön. Ich redete von mp3, jetzt sind wir bei DAB. Das kann ich echt nicht brauchen. Wollte nix senden. | | Ist aber fast das Gleiche, nur, daß da MP2 verwendet wird :)
Wenn ich mich auf dieser Ebene bewegen wollte, dann könnte ich auch gleich einen mp4-Strom erzeugen.
DAB wird nur von den Großen bespielt.
- Henry
--
"Ralph A. Schmid, DK5RAS" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com... | "Henry Kiefer" wrote: | | >Klaro. Hast du was anderes erwartet? | | Natürlich nicht, ich hätte mich eher gewundert, würde für so ein | Nischengerät ein eigener chip entwickelt.
Kleinere Firmen/Entwicklergruppen haben nicht die Ressourcen einen speziellen DSP auf die Beine zu stellen. Erstaunt mich, wenn es dazu nichts gibt, dafür aber 200 verschiedene PIC-Selbstbauprogrammieradapter.
| | >Die Software wird billig in Bangalore oder noch billiger irgendwo geschrieben. Der DSP ist | >leistungsfähig genug, praktische ALLE anfallenden Arbeiten zu erledigen. Und wenns full-custom ist, dann wird auch gleich noch der | >Display-Controller draufkommen. | | Yep. | | >Das ist aber für kleinere Entwickler nicht machbar. | | Doch, durchaus...
Nicht mein Spezialgebiet. Würde erhebliche Zeit kosten, sich/mich da reinzuarbeiten. Und wenn, dann kann man nur was fertig ausgearbeitetes implementieren, weil ansonsten ist man ganz schnell bei Matlab und höheren Mathematik/DSP-Kenntnissen angekommen.
- Henry
--
Wenn du sowieso keinen Atmel nimmst, könnte man natürlich einen uC nehmen, für den es schon eine USB-Mass-Storage-Lösung gibt. Dann könnte man den Beantworter wie 'ne USB-Festplatte benutzen.
Ansonsten halt zwischen zwei Karten wechseln, kosten ja nix mehr. Ist evtl. sowieso praktischer, weil man den Anrufbeantworter nicht unbedingt in USB-Reichweite aufstellen will. Die Standardfunktionen Ansage aufnehmen, abhören, etc.. sollte das Gerät doch wohl sowieso ohne PC-Hilfe meistern können, oder?
-- thomas.kindler@gmx.de, www.bredobrothers.de www.microsoft-hellhounds.de
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.