Dotaz: Naharavani zvuku a kresleni spektrogramu

[tuxmartin]

Příloha:

• spectrogram.png (291222 bytů)

Ahoj,
potrebuju nahravat zvuk a generovat z nej za urcite casove useky spektrogram (neco jako obrazek v priloze).

Z 99% se bude nahravat pouze sum, zajimaji me anomalie, ktere na histogramu dobre poznam.

Proteze bude zarizei pripojene pres mobilni internet, rad bych co nejmensi prenos dat.
Sice nemam M2M rarif, ale treba T-Mobile u nej chce 21Kc/MB => mobilni net je vzdy drahy...
Neresete prosim veci typu jak na misto dotahnout wifinu.

Staci hodne spatna kvalita zvuku, zkousel jsem arecord s S16 a asi to bude OK. Ale usporne na misto to zrovna neni, takze musim pouzit nejaky kodek. Ale jaky?

Uvazoval jsem o speex, ale ten mozna je dobry jen na mluvene slovo. Ja nechci zastavit nahravani, pokud se nemluvi, nahravat se musi porad.

Spektrogramu jsem zkousel kreslit pres sox, ale neumi na vstupu zpracovat speex, musim mu dat treba wav. A to je dalsi problem, proc nejde z ffmpeg poslat rourou do sox zvuk?

$ arecord -f S16_LE -c1 -r8000 -t raw | speexenc - --le S16_LE.SPX

$ sox S16_LE.SPX -n spectrogram
sox FAIL formats: no handler for file extension `SPX'

$ ffmpeg -i S16_LE.SPX -f sox - |  sox - -n spectrogram
ffmpeg version 0.8.13-6:0.8.13-0ubuntu0.13.10.1, Copyright (c) 2000-2014 the Libav developers
  built on Jul 15 2014 13:48:35 with gcc 4.8.1
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
Input #0, ogg, from 'S16_LE.SPX':
  Duration: 00:00:19.43, start: 0.005000, bitrate: 16 kb/s
    Stream #0.0: Audio: libspeex, 8000 Hz, 1 channels, s16
Incompatible sample format 's16' for codec 'pcm_s32le', auto-selecting format 's32'
Output #0, sox, to 'pipe:':
  Metadata:
    encoder         : Lavf53.21.1
    Stream #0.0: Audio: pcm_s32le, 8000 Hz, 1 channels, s32, 256 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press ctrl-c to stop encoding
sox FAIL formats: can't open input  `-': can't find sox file format identifier


$ ffmpeg -i S16_LE.SPX S16_LE.WAV
$ sox S16_LE.WAV -n spectrogram
$ # ted je to ok

Ziskana data potrebuju posilat pres mobilni net na centralni server a tam je asi 2 roky archivovat (nereste vyznam archovace sumu ). Jak nejlepe ukladat? Nejaky zvukovy soubor? Ale jaky kodek?
Kdyz pouzivam arecord s S16 pise to "Signed 16 bit Little Endian, Rate 44100 Hz, Stereo", co to presne je? 16bit integer? Takze bych mohl ukladat v databazi zvuk jako cisla? To je asi velka blbost...

Spektrogram budu generovat treba na 12 hodin zvuku, ale rad bych mel moznost generovat i za jine obdobi. Takze nemuzu archivovat obrazky, ale musim mit zvukove soubory. Kvuli prenosu dat mozna budu pres mobilni internet posilat jen vygenerovany obrazek za 12 hodin a zvukove soubory ukladat jen na SD kartu. Uvidim podle velikosti. System bude asi OpenWrt na nejakem wifi routeru.

• Jakym programem nahravat?
• Do jakeho kodeku?
• Cim kreslit spektrogramy? Ty se nemusi malovat na OpenWrt, ale klidne az na serveru. Nebranil bych se Java kreslitku (na serveru jede Tomcat). Na presnos dat zase vychazi lepsi obrazek, nez zvukovy soubor.

Odpovědi

[Jendа]

T-Mobile má i datovou předplacenku Twist za 0,4Kč/MB.

Kreslení spektrogramu a detekci artefaktů si ukradni ze szdc, je tam triviální example na FFTW a Goertzela.

U komprese strašně záleží na tom, co tam bude. Pokud tam bude mluvené slovo, tak bych to komprimoval Vorbisem. Při samplerate 11025 se dá dostat na nějakých 20 kb/s. Pokud tam budou třeba data, tak to Vorbisem šeredně zkurvíš.

Nahrávané soubory bych rozsekával třeba po hodinách.

Přijde mi zbytečné posílat na server šum. Udělej lokálně detekci (viz szdc) a pošli ven jenom zajímavé kousky. Zbytek archivuj lokálně.

V žádném případě nedělej detekci ani kreslení spektrogramu ze zkomprimované verze (jak to máš v příkladu), komprese to domrví.

Jakym programem nahravat?

arecord. Nastav mu přes -r menší samplerate a -c 1, protože nepotřebuješ stereo.

Cim kreslit spektrogramy?

FFTW + custom export do nějakého obrázku, pokud ti jde o výkon (to by mělo zvládnout i to WRT). Nebo něco v pythonu

import matplotlib.pyplot as plt
fig = plt.figure(figsize=(wfsize/100,samples/100+2), dpi=100)
ax = plt.Axes(fig, [0., 0., 1., 1.])
ax.set_axis_off()
fig.add_axes(ax)
ax.imshow(wf, aspect="normal")
plt.savefig("o.png",bbox_inches='tight')

To je asi velka blbost...

Proč by to měla být blbost? Všechno v počítači jsou čísla . Ukládat ale jednotlivé samply do databáze už blbost je, protože jich je strašně moc.

[dustin]

Pokud platíš za přenesená data, přijde mi také zbytečné přenášet šum. Analyzoval bych přímo na zdroji a přenášel jen ty artefakty.

Píšeš OpenWRT - předpokládám zvukovka přes USB. Běžné USB zvukovky umí nejnižší vzorkování 44100Hz, to je možná pro tvé účely zbytečně mnoho. Navíc USB audio, pokud není upravený driver, vyžaduje větší péči CPU než např. PCI, kterému lze nastavit větší buffer/period time a zvukovka přes DMA ukládá data sama, bez potřeby CPU. Píšu to proto, že ke zpracování budeš potřebovat celkem stálý výkon CPU a když dojde k xrunu (CPU nestihne odebrat data od zvukovky), máš krásný artefakt, který jsi ale určitě nechtěl. A k tomu u slabého routeru s USB zvukovkou určitě občas dojde.

Neznám detaily, ale pokud by stačil samplerate třeba 16kHz nebo i 8kHz, zvolil bych nějakou úspornou x86 desku s PCI slotem, do ní zvukovku nativně podporující takhle nízké vzorkovací frekvence, případně desku s integrovanou zvukovkou podporující nízké vzorkování (typicky IntelHDA). Nastavil bych co největší buffer/period time (pro minimalizaci rizika xrunu) a analyzoval to na té desce. SW: arecord na nahrávání přímo z hw:X, analýzu třeba v těch sdr toolech, ty jsou docela optimalizované, co jsem četl (praktickou zkušenost s nimi nemám) a přesně k těmto účelům se používají. Možná umí i samy nahrávat, to je to nejmenší.

[Jendа]

analýzu třeba v těch sdr toolech, ty jsou docela optimalizované, co jsem četl (praktickou zkušenost s nimi nemám)

Kvalita dost kolísá. Třeba v gnuradiu jsou některé bloky (osmosdr source) zoufale pomalé a jiné jsou v pohodě.

[Jendа]

(resp. přehazování dat v gnuradiu má prostě dost velký overhead)