KiCad (Wikipedie), sada svobodných softwarových nástrojů pro počítačový návrh elektronických zařízení (EDA), byl vydán v nové major verzi 10.0.0 (𝕏). Přehled novinek v příspěvku na blogu.
Letošní Turingovou cenu (2025 ACM A.M. Turing Award, Nobelova cena informatiky) získali Charles H. Bennett a Gilles Brassard za základní přínosy do oboru kvantové informatiky, které převrátily pojetí bezpečné neprolomitelné komunikace a výpočetní techniky. Jejich protokol BB84 z roku 1984 umožnil fyzikálně zaručený bezpečný přenos šifrovacích klíčů, zatímco jejich práce o kvantové teleportaci položila teoretické základy pro budoucí kvantový internet. Jejich práce spojila fyziku s informatikou a ovlivnila celou generaci vědců.
Firefox 149 dostupný od 24. března přinese bezplatnou vestavěnou VPN s 50 GB přenesených dat měsíčně (s CZ a SK se zatím nepočítá) a zobrazení dvou webových stránek vedle sebe v jednom panelu (split view). Firefox Labs 149 umožní přidat poznámky k panelům (tab notes, videoukázka).
Byla vydána nová stabilní verze 7.9 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 146. Přehled novinek i s náhledy v příspěvku na blogu.
Dle plánu byla vydána Opera GX pro Linux. Ke stažení je .deb i .rpm. V plánu je flatpak. Opera GX je webový prohlížeč zaměřený na hráče počítačových her.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.27.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byly publikovány informace (technické detaily) o bezpečnostním problému Snapu. Jedná se o CVE-2026-3888. Neprivilegovaný lokální uživatel může s využitím snap-confine a systemd-tmpfiles získat práva roota.
Nightingale je open-source karaoke aplikace, která z jakékoliv písničky lokálního alba (včetně videí) dokáže oddělit vokály, získat text a vše přehrát se synchronizací na úrovni jednotlivých slov a hodnocením intonace. Pro separaci vokálů využívá UVR Karaoke model s Demucs od Mety, texty písní stahuje z lrclib.net (LRCLIB), případně extrahuje pomocí whisperX, který rovněž využívá k načasování slov. V případě audiosouborů aplikace na
… více »Po půl roce vývoje od vydání verze 49 bylo vydáno GNOME 50 s kódovým názvem Tokyo (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Článek na stránkách Fedora Magazinu informuje o vydání Fedora Asahi Remixu 43, tj. linuxové distribuce pro Apple Silicon vycházející z Fedora Linuxu 43.
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.
Přesně tak. Já si myslím, že pro nenáročný poslech by AAC+ těch 32kbps bohatě stačilo.
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.
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).
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.
[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)
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
Nejsem původní tazatel, ale díky moc! Toho jsem si nikdy nevšiml..
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.
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.
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.
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.
> 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?
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.
Mně tak nějak dostačuje 64kbps Vorbis nebo 128kbps MP3
Je to VBR právě někde kolem těch 200 kb/s bych řekl...
Máš v počítači něco ve FLACu(nebo jinak bezeztrátově zkomprimované)?
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.
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).
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.
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.
Tiskni
Sdílej: