Hnus plechovej aneb vysoká kvalita zní jinak

10.5.2009 09:51 | Přečteno: 2164×

Poslouchám analogové rádio. To potřebuju vypnout, ale zároveň mohu zapnout internetové, tak zabrousím na stránky dotyčné stanice a kliknu na odkaz kvalita: vysoká (128 kbps). Vyskočí popup, v něm se otevře stránka se zplužinovaným totemem a rádio hraje. Ovšem nějak plechově. Po chvíli jsem přišel na to, že chyba není na mé straně. Vizte rekonstrukci pomocí wgetu a mplayeru:

david@cihla:~$ wget -qO- 'http://www.abradio.cz/player.php?kod=201&quality=asx128' |grep heybrno128
        <param NAME="URL" VALUE="asx/heybrno128.asx" >
        <embed type="application/x-mplayer2" name="iRadio2" ShowStatusBar="1" src="asx/heybrno128.asx" width="370" height="65"></embed>
david@cihla:~$ wget -qO- http://www.abradio.cz/asx/heybrno128.asx |grep mms
<Ref href = "mms://kocka.limemedia.cz/heybrno?WMContentBitrate=135000" />
david@cihla:~$ mplayer mms://kocka.limemedia.cz/heybrno?WMContentBitrate=135000
MPlayer 1.0rc2-4.3.3 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) M processor 1600MHz (Family: 6, Model: 9, Stepping: 5)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing mms://kocka.limemedia.cz/heybrno?WMContentBitrate=135000.
STREAM_ASF, URL: mms://kocka.limemedia.cz/heybrno?WMContentBitrate=135000
Resolving kocka.limemedia.cz for AF_INET6...
Couldn't resolve name for AF_INET6: kocka.limemedia.cz
Resolving kocka.limemedia.cz for AF_INET...
Connecting to server kocka.limemedia.cz[90.183.101.184]: 1755...
Connected
unknown object
unknown object
file object, packet length = 5493 (5493)
unknown object
stream object, stream ID: 3
unknown object
unknown object
data object
mmst packet_length = 5493
Cache size set to 64 KBytes
Cache fill: 12.50% (8192 bytes)   
ASF file format detected.
[asfheader] Audio stream found, -aid 1
[asfheader] Audio stream found, -aid 2
[asfheader] Audio stream found, -aid 3
Clip info:
 name: Hey Brno
 author: AB radio a.s.
 copyright: AB radio a.s.
==========================================================================
Forced audio codec: mad
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 32000 Hz, 2 ch, s16le, 32.0 kbit/3.12% (ratio: 4000->128000)
Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))
==========================================================================
AO: [pulse] 32000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
overflow in spectral RLE, ignoring37440.0 (-24.-8) 11.3% 25% 
overflow in spectral RLE, ignoring
A:3447694.8 (957:41:34.7) of 2133437440.0 (-24.-8)  9.9% 25% 
Exiting... (Quit)

       

Anketa

Komentáře

[Nicky726]

Když ono to není jen o datovém toku, ale i o použitém kodeku. Kdysi jsem zkoušel .mp4 od Nera a výsledek byl znatelně lepší než .mp3 o stejném datovém toku.

[stativ]

Jojo, AAC je mezi ztrátovými formáty špička. Nedávno jsem narazil na skvělou ukázku jeho schopností. Není to sice nic extra náročného, ale mp3 by v 32kbps zněla nesrovnatelně hůř.

[Grunt]

Jojo, AAC je mezi ztrátovými formáty špička.

No, záleží jak kde. SBR jeho největší výhoda je IHMO i jeho největší nevýhoda. Samozřejmě, na 32kbps se není moc o čem bavit, ale na hranici 32kbps - 64kbps je to boj mezi AAC+ a Vorbisem a na 64kbps zase není co řešit. Docela by mě zajímalo jak by vypadal Vorbis s SBR a parametrickým stereem.

Nedávno jsem narazil na skvělou ukázku jeho schopností.

Tak to bohužel ještě není využití všech jeho schopností. Je to totiž kódované pomocí 3GPP implmentace AAC+ kodeku(ve většině distribucí v balíčku aacplusenc), která sice používá SBR(jestli parametrické stereo, netuším) ale špičkou stále je převodník v zakoupeném Neru.

Není to sice nic extra náročného, ale mp3 by v 32kbps zněla nesrovnatelně hůř.

MP3 se nedá ohánět, leč ta by nezněla nijak. U tak nízkého datového toku odmítá 44100Hz kódovat.

[Grunt]

Přesně tak. Já si myslím, že pro nenáročný poslech by AAC+ těch 32kbps bohatě stačilo.

[xvasek]

Ono je to IMHO tak, že na jednu stranu AAC, Vorbis, nebo třeba i to - zde nepříliš populární - WMA jsou celkem perfektní kodeky a 128kbps je celkem dobře poslouchatelných; mp3 na 128kbps dejme tomu s přimhouřeným okem označím za "pro nenáročné účely" vyhovující - do autorádia, do telefonu, kde mám sluchátka obyčejné "pecky" apod. Na stranu druhou jsem ale ještě nenašel internetové rádio, které by znělo fakt dobře, i když používá třeba 128kbit AAC nebo WMA - vždycky je to hnus plechový. Kde se v průběhu přenosu / reprodukce vyskytuje chyba netuším.

[petr_p]

Český rozhlas vysílaný Cesnetem.

[kotrcka]

hmm.. nie je (alebo aspon nebolo) to na abradiu tak, ze 128 kbit bol len pri zaplateni nejakeho poplatku? inak 32 kbit (niekde dokonca 16).

[Vašek Lorenc]

Zkusil bych místo mplayeru pustit na ten samý stream VLC. Proti WMA streamům bývá znát zlepšení -- neznám technické detaily, ale skoro to vypadá, jako by client-server měl v sobě nějaký handshake, jak kvalitní tok vlastně chce.

[David Jaša]

Hm, tak jsem to zkusil a ono to fakt funguje:

[00000409] access_mms access: selecting stream[0x1] audio (125 kb/s)
[00000409] access_mms access: ignoring stream[0x2] audio (63 kb/s)
[00000409] access_mms access: ignoring stream[0x3] audio (32 kb/s)

[Grunt]

Nechci do toho kecat, ale ono to docela jasně dává najevo i ten Mplayer:

Connecting to server kocka.limemedia.cz[90.183.101.184]: 1755...
Connected
unknown object
unknown object
file object, packet length = 5493 (5493)
unknown object
stream object, stream ID: 3
unknown object
unknown object
data object
mmst packet_length = 5493
Cache size set to 64 KBytes
Cache fill: 12.50% (8192 bytes)   
ASF file format detected.
[asfheader] Audio stream found, -aid 1
[asfheader] Audio stream found, -aid 2
[asfheader] Audio stream found, -aid 3

Stačí mplayer "mms://kocka.limemedia.cz/heybrno?WMContentBitrate=135000" -aid 1

[Vašek Lorenc]

Nejsem původní tazatel, ale díky moc! Toho jsem si nikdy nevšiml..

[Grunt]

Jak si potom přepínáte zvukové stopy u MPEG/Matrosky/DVD? Teď jsem si vlastně ještě uvědomil, že by to mělo jít i přímo za běhu klávesou #, ale u ASF streamu to nějak nefunguje.

[Vašek Lorenc]

Není to tak, že bych ten parametr neznal, jen mě v tomhle kontextu nenapadl.. a ano, běžně používám spíš tu klávesovou zkratku.

[David Jaša]

Tudíž mplayer a gstreamer jsou zabugované, když si nevyberou ten správný stream.

[Grunt]

Těžko říct. První chyba je určitě na straně rádia. Samotný Microsoft označil MMS za zastaralý, ukončil jeho podporu v Microsoft Media Serveru 2008 ve prospěch RTSP a RTSP také doporučil používat. Ale budiž. Prostě nejsou prachy na nákup nového MM Serveru (že tu máme X freewarových nebo úplně otevřených variant mnohdy s mnohem lépe popsanými transportními protokoly a efektivnějšími kodeky je očividně irelevantní) a jednou bylo MMS defaultní, tak tak bude i nadále. Další problém je v MMS samotném. Tento transportní protokol dříve nebyl vůbec popsán(co jiného také od Microsoftu čekat) a jeho dřívější implementace vznikly na základě reverse engineeringu. Nevím jestli je to nekompletní/špatná implementace, nestandardní rozšíření či jiná verze protokolu, ale hlavní příčina asi bude ležet zde:

Connecting to server kocka.limemedia.cz[90.183.101.184]: 1755...
Connected
unknown object
unknown object
file object, packet length = 5493 (5493)
unknown object
stream object, stream ID: 3
unknown object
unknown object
data object
mmst packet_length = 5493
Cache size set to 64 KBytes

Pak dál v tom hrají roli staré implementace fallback kodeků/protokolů v samotné libav. Krom toho, že Mplayer, FFMpeg a gstreamer používají různé externí knihovny pro (de)muxování/(de)kódování používají ještě jako fallback interní implementace pokud knihovny na systému nejsou k dispozici(u mplayeru se vyznačují tím, že mají před jménem ff, takže ffvorbis,fflibdirac,ffaac,…). Ty jsou ovšem často dost staré nebo rozbité nebo něco takového a jsou tam jen z toho důvodu, že jedou. FFaac kašle na SBR, FFvorbis u 64kbps produkuje nějaké příšery a ne Vorbis, FFflac při přehrávání 32-bitového zvuku generuje do jednoho sluchátka zvuk, do druhého jakýsi šum, atd. No a fallback implementace MMS je na tom nejinak:

stream/asf_mmst_streaming.c:
/*
 * MMST implementation taken from the xine-mms plugin made by
 * Major MMS (http://geocities.com/majormms/).
 * Ported to MPlayer by Abhijeet Phatak 
 *
 * Information about the MMS protocol can be found at http://get.to/sdp
 *
 * copyright (C) 2002 Abhijeet Phatak 
 * copyright (C) 2002 the xine project
 * copyright (C) 2000-2001 major mms
 *
 * This file is part of MPlayer.
 *
 * MPlayer is free software; you can redistribute it and/or modify
…

Myslím, že o tom dost svědčí nejnovější verze této implementace, která nese číslo 0.0.3. Stačilo by kdyby portovali MMS implementaci z projektu VLC či jiného podobného projektu. Dále je chyba také v tom kdo ten mplayer balil. Jak už jsem řekl, tak mplayer sice používá záložní interní implementace, ale spoléhá většinou na externí knihovny(přece jen se lépe upgraduje jedna knihovna než celý mplayer). To že se použila interní implementace svědčí o tom, že v době překladu nebyly k dispozici hlavičkové soubory pro Live555, NeMeSi,libmms a nebo bůhví vůbec kterou transportní knihovnu(a nebo je mplayer přeložen s volbou --enable-dynamic-plugins a ani jeden z nich není nainstalován). No a nakonec je dost možné, že v tom celém má prsty i samotný mplayer, protože v návodu má napsáno:

       -aid <ID> (also see -alang)
              Select  audio  channel (MPEG: 0-31, AVI/OGM: 1-99, ASF/RM: 0-127, VOB(AC-3): 128-159, VOB(LPCM): 160-191, MPEG-TS 17-8190).  MPlayer prints the available audio IDs
              when run in verbose (-v) mode.  When playing an MPEG-TS stream, MPlayer/MEncoder will use the first program (if present) with the chosen audio stream.

A třeba to vůbec nemusí být chyba. Pokud vím, tak nikde není napsáno, že první stopa musí mít nejvyšší bitrate, takže by stačilo kdyby nejvyšší bitrate byla v třetí stopě a nikdo by si ani ničeho nevšimnul.

[David Jaša]

Opravuju můj předchozí příspěvěk v souladu s principem robustnosti na:

Tudíž mplayer, gstreamer a abradio.cz jsou zabugované, když si nevyberou ten správný stream.

[Grunt]

A nebo se to dá také interpretovat takto: V Microsoftu jsou prasata a v abradio.cz lamy. Jednoznačný (a hlavně tak jednoduchý) závěr bych nedělal dokuď bych opravdu nevěděl kdo tu chybu, že hraje 32kbps namísto 128kbps, udělal.

[Ondrej 'SanTiago' Zajicek]

> Tudíž mplayer a gstreamer jsou zabugované, když si nevyberou ten správný stream.

Jak ma asi mplayer vedet, ktery stream uzivatel bude preferovat? Zda vetsi kvalitu, nebo vetsi usporu linky? Co kdyby uzivatel byl treba na rychle lince, ale placene podle poctu prenesenych dat?

[David Jaša]

Nějak podle té URI. Pro každou bitrate je jiná, ač je stream stejný.

[Grunt]

A jo, až teď jsem si toho všiml. Tak to můžu jednoznačně říct:V Microsoftu jsou prasata a v abradio.cz lamy

[Grunt]

Přílohy:

• Snímek obrazovky-Frekvenční analýza.png (35982 bytů)
• spectrum.txt (24691 bytů)

Jak už jsem se výše zmínil, mplayer v případě že nemá dostupné knihovny používá interní implementace. U WMA je to ffwmav2, což je otevřená implementace tohoto kodeku (na kterou je celý tým docela pyšný, mohu-li dodat). Pokud používá VLC nějaký starší branch Libavcodecs je dost možné, že se ještě stále používá wmadmo namísto ffwmav2. Wmadmo je wrapper na DLL knihovnu, která je vypáraná ze samotných Windowsů a je obsažena v balíku win32codecs. Vzal jsem jeden WMA soubor, dekódoval ho oběma knihovnami a už to vyprodukovalo absolutně odlišné soubory. Vložil jsem je do audacity a krom zarovnání zas tak odlišně nevypadaly. Zarovnal jsem je přesně na sebe s přesností na bajt, spodní track jsem invertoval a výsledek smíchal a vykreslil. Na první pohled to udělalo jednu rovnou a úplně tichou čáru, na druhý pohled zas tak rovná nebyla. Což může být ten důvod.

 

[Limoto]

Mně tak nějak dostačuje 64kbps Vorbis nebo 128kbps MP3

[Zdeněk Štěpánek]

Se nediv kdyz poslouchas WMA format, to zni priserne v jakymkoliv bitrate.

Si pust ogg a budes spokojenej.

Ke kontrolu muzu doporucit cesky rozhlasy a nebo www.danceradio.cz, to nabizi vsechny mozny formaty vcetne ogg ve 256kbps, tam uz proste neni co resit.

WMA je prisernost, MP3 je priserny jen o kousek min (za minimum povazuju 192, nejlepe 256kbps VBR), pak je dlouho dlouho nic a na spicce je jednoznacne ogg. O AAC toho ale moc nevim, jen to ze se na nej vazou nejaky patenty, takze me nezajima.

Zdenek

[YYY]

Ja jsem skoro hluchy, takze mi 64kbps absolutne dostacuje.

[David Watzke]

192 kb/s mp3 (nebo preset standard) je pro mě OK ve většině případů.

[Zdeněk Štěpánek]

Standard je 128 ne? Ja kdyz uz koduju do mp3 jak pouzivam preset insane, tam uz to mp3 cvrlikani vetsinou neslisim.

Nejvic miluju kdyz to slisim v analogovym radio, to je hnus velebnosti...

Zdenek

[David Watzke]

Standard *rozhodně* není 128, to bych řval Je to VBR právě někde kolem těch 200 kb/s bych řekl...

[Grunt]

Máš v počítači něco ve FLACu(nebo jinak bezeztrátově zkomprimované)?

[David Watzke]

Ne, asi ne. Ale to bych už nejspíš ve většině případů nepoznal. Nemám moc dobrej sluch.

[Grunt]

Ne, asi ne.

Pokud to nebyla ironie, tak si nějaké stáhni, převeď do WAVu, zkomprimuj do MP3 o 128kbps(či jiné libovolné bitrate na kterou si troufáš. Jediné pravidlo: Vypni Replay Gain), první WAV otevři v audacity a přihoď k němu jako track tu MP3. Pokud nejsou zarovnané, tak je zarovnej. Označ celý druhý track -> Efekty -> Invertovat. Potom vyber oba tracky a Stopy -> smíchat a vykreslit. Teoreticky by si měl dostat rozdíl mezi oběma signály což by teoreticky mělo být to co MP3 zahazuje a nebo si vymýšlí. Pak si to pusť a zkus říct, zda-li nejsi schopen to šumění a pleskání oželet. Něco bych i poslal, ale komprimovat právě ten rozdíl a nebo někam strkat 60MB.

Ale to bych už nejspíš ve většině případů nepoznal. Nemám moc dobrej sluch.

Ale dostatečně dobrý aby si u 128kbps řval.

[thingie]

No, celkem libovolný zvuk se ale dá rozebrat na několik stop nesmyslného pískání nebo něčeho takového. Co je to za metodu?

[David Jaša]

odečtení těch dvou signálů od sebe.

[trekker.dk]

Docela bych se divil, kdyby to fungovalo přesně. Stačí, když ta komprese ten zvuk o pár vzorků posune a místo přesného výsledku dostaneš hausnumera...

[Grunt]

Ne hausnumera ale funguje to jako nějaký filtr nebo ekvalizér. O co větší posun, o to nižší frekvence ve výsledku budou. Je pravda, že MP3 dává na začátek nějakou prodlevu a pak počas samotného průběhu to asi také ještě nějak zarovnává, ale dá se to překrýt docela přesně s přesností na jeden vzorek. Uznávám, že to není úplně košer, ale nic lepšího mě nenapadlo. Co takhle skládat přímo rozdíl v jednotlivých framech během kvantizace? To už by mohlo být, ne? Ale myslím si, že pro přibližnou představu to stačí. Viz. ukázka v MP3 o 128kbps(originál by mohl být někde tady).

[Grunt]

Je pravda, že MP3 dává na začátek nějakou prodlevu a pak počas samotného průběhu to asi také ještě nějak zarovnává

Na druhou stranu, toto je featura MP3. Ogg Vorbis dobíhá na sampl přesně s originálem. Možná má nějaké rozestupy v průběhu, ale to už se zase dá brát jako regulérní diference.

[thingie]

No to vidím, ale jaký to má smysl? Jenom proto, že v té druhé stopě neslyším nic smysluplného, tak můžu předpokládat, že nevadí, že tam není?

[David Watzke]

Ale dostatečně dobrý aby si u 128kbps řval.

No dobře, "řval" je přitažený za vlasy

Zkoušel jsem to s tím audacity, vzal jsem orig. CD, grabnul z něj wav, převedl ho pomocí lame --noreplaygain -h -b 128 a pak jsem to zkusil zarovnat jak jen to šlo... a po provedení toho cos mi popsal mi zbyl slušnej bordel. Na druhou stranu abych pravdu řekl, tak takovou 128 kb/s mp3 vytvořenou z originálu bych nejspíš nevnímal jako něco hroznýho. Přesto už jsem se setkal s dost mp3 ve 128 kb/s, který se fakt nedaly poslouchat, ale kdo ví, co s tím ten člověk dělal. A nakonec taky záleží na tom co a na čem člověk poslouchá. Zkoušel jsem Rammstein - Engel a poslouchal jsem na tomhle.