猴硐 (車站、神社、貓村)

週末搭火車去猴硐吸個貓,本篇與技術無關,另外請注意圖多。另外照片都已經丟到 Flickr 上了,也可以自己翻。

主要是因為我跟我老婆都有北北基的 TPASS ($1200/30days 的版本),加上也放在名單裡面一陣子了,這個週六剛好天氣還不錯就從搭台鐵過去,搭區間快車,12:09 從板橋上車,13:12 就到了,早一點先到板橋站買了個台鐵便當

這應該是最方便的交通方案了,下車時可以發現有不少外國遊客。

下車後本來是計畫要先去猴硐神社的,結果走錯方向 (往北跑),但意外看到還蠻漂亮的河床:

然後是路上意外發現這邊也有 foodpanda 的送貨箱子:

回頭走的時候就看到一隻貓貓,看起來有點狀況,不過先前查資料的時候得知猴硐有機制在管理,應該是會有人照料:

另外看到一隻躲在陰影下面納涼的貓貓:

接著就順著地圖走找神社,不算太難找,不過我們是從猴硐路上去,然後從北 37 線下去,所以會先看到涼亭:

涼亭旁邊有說明:

下來到北 37 線後後會看到鳥居以及同樣的告示牌,如果偏好從鳥居上來的話可以從北 37 線這邊進來:

接著在遠處有看到桐花,拿起相機試著拍幾張:

接著就繼續往猴硐貓村走,先走回猴硐車站,然後從二樓的走道可以進入貓村,只要遠遠看到有一群人圍著,就大概知道有貓在那邊了... 這邊就有很多貓貓:

接著就到咖啡廳裡面吹冷氣當作猴硐這邊的最後一站,順便看看店貓:

預定的下一站是要去九份看看,先看了台鐵的發車時間,然後早了一點離開,從另外一側的樓梯下去,再多吸幾隻貓貓:

還有躲到廢棄屋子裡面的貓貓:

以及我老婆在看上面那隻貓貓,結果被其他貓貓跑過來反吸兩口,沒注意到結果後退的時候嚇到貓貓:

然後繼續下樓看到的:

以及在水塔旁邊喝水的貓貓:

最後是在車站通道上也看到一隻貓貓趟在旁邊,以及公所的告示:

對於有 TPASS 的人來說算是不錯的半天行程,要注意的是當地沒有便利超商,建議帶個裝滿水的水壺過去,或是在出發的地方先買好水。

Google 推出 Jpegli:JPEG 的 encoder 以及 decoder

Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」,原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小:

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較,大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了,應該是跟 cjpeg 比,如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯,這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品:

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名,比較熟的是 Zopfli 以及 Brotli

把 MIT license 當歌詞寫歌...?

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推,把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai?):

WTF...

npm 被拿來放影片...

這邊講的 npm 是指 official repository... 在 Lobsters 上看到在 npm 上放 ts 檔的文章:「npm flooded with 748 packages that store movies」,原文在這:「npm flooded with 748 packages that store movies」。

發現問題的是 wlwz 這個 user (不確定什麼時候會不見,不過備份在 Internet ArchiveArchive Today 上都有)。

以列出來的第一個 wlwz-2312-1405 來看,可以從裡面看到十個 ts 檔:

找了一下字串,看起來中國那邊有人認出來是「武林外傳」了 (縮寫剛好就是 wlwz):「npm 被用来保存盗版视频」。

這算是是各種 hosting 需要面對的問題...

Ruffle 對 crossdomain.xml 的處理方式

ruffle 是一個 open source 的 Flash 模擬器,用 JavaScript (以及 WebAssembly) 讓使用者可以在瀏覽器裡面直接執行。

不過想到 Flash 的 crossdomain.xml 在技術上應該是沒辦法繞過瀏覽器對 CORS 的限制,所以找了一下目前的情況... 在「Ideas for getting arounds CORS restrictions #8972」這邊有提到兩個方法,另外 comment 提到了「Add setting to spoof URLs in network requests #1486」這個。

看起來這個問題還在「有點子,但沒解決」的情況。

不過找了一下當年有玩的小遊戲 Zookeeper,在「Zookeeper - Flash Games Archive | FlashArch」這邊可以玩,看起來功能都還算正常,讓人懷念啊...

美國大麥克的價錢

Hacker News 上看到「A site that tracks the price of a Big Mac in every US McDonald's (pantryandlarder.com)」這個,追蹤美國麥當勞裡的大麥克價錢:「McCheapest」。

這個明顯跟「大麥克指數」有關,而且因為美國不同州會有不同的稅務結構,所以可以預期不同地區的麥當勞價位不同,不過沒有預期到同一個州裡面也是各家店自行定價的...

目前網站上列出來最便宜的是奧克拉荷馬州的 US$3.49,最貴的在麻薩諸塞州的 US$8.09,價差到一倍以上... 順便提一下,目前在台灣大麥克的價錢是相同的 NT$75,約 US$2.4。

另外一個感到驚訝的是麥當勞東半部的密度比西半部高好多?還是這張資料沒顯示出來而已?

世紀帝國系列裡的 AoE 與 AoK 使用組合語言加速的情況

Age of Empires (1997) 與 Age of Empires II: The Age of Kings (1999) 是當年兩個很紅的遊戲,有傳言裡面有很大一部分是用組合語言寫的。

剛剛在 Hacker News 上看到「Original Age of Empires 2 dev talks about its usage of assembly code (reddit.com)」這篇,看起來是原作者跳出來說明這段傳言 (講的更細),原文在 Reddit 的「AoE is written in Assembly - is this actually TRUE?! :O : aoe2」這邊。

32-bit 的 x86 組語部分有大約 13k 行,大多數 (11.5k 行) 是與繪圖有關的 (當年繪圖相關的功能都還是 CPU 在算):

There were about ~13,000 lines of x86 32-bit assembly code written in total.

The vast majority, about ~11,500 lines worth, was in the 'drawing core', which drew SLP sprites in a variety of ways (mirrored, stippled, clipped). The code for this was in a separate .asm file, which was "compiled" by Microsoft Macro Assembler 6.1 into a .obj file.

最主要的目的當然是效能,這邊提到隔壁棚的星海爭霸預設還是 640x480 的時候,AoE 這邊預設可以上 800x600:

The use of assembly in the drawing core resulting in a ~10x sprite drawing speed improvement over the C++ reference implementations, and AoE's drawing core was notably faster than competitors like StarCraft, which is why the default resolution 'out of the box' for AoE was 800 by 600, when nearly all our competition was 640 x 480 resolution - we could scroll the screen and fill it with sprites as fast or faster even though we had twice as many pixels-ish in the game world area.

後來到 64-bit 年代就變成用 C++,主要是因為 compiler optimization 的改進,以及多 CPU 與 multi-threading 的技術,讓計算力提升很多:

I re-wrote the assembly functions into C++ for both Definitive Editions, as they are 64-bit programs, and inline assembly was never supported by the 64-bit C++ compiler, and the vastly improved register sets and compiler optimizations made it un-necessary. Additionally, sprite drawing in the definitive editions is multi-threaded, and will use up to 4 cores for that task alone.

算是時代的演進,意外的留下一些記錄... 而更後面的時代則是把這些計算 offload 到顯卡上面了。

用 Astrometa DVB-T2 聽 FM 廣播

算是接續「用 Astrometa DVB-T2 收數位無線電視台 (DVB-T)」這篇的內容,上篇有提到在台灣可以收 DVB-T 的數位電視內容,另外也有提到裡面的 RTL2832U 可以收 FM 廣播。

RTL2832U 在 Linux 下面的 FM 介面不是 /dev/radio0 這種 Radio Interface,而是透過 SDR 的方式,會產生出 /dev/swradio0 操作。

所以可以用 rtl_fm 這個工具從 SDR source 轉成 PulseAudio 吃的格式,像是要聽 107.7MHz 的台北之音,可以用這樣的指令聽:

sudo rtl_fm -f 107700000 -s 441000 -r 44100 | aplay -r 44100 -f S16_LE

但這樣做會是 mono (單聲道),這點可以從「Stereo FM receiving with RTL-SDR and Gnuradio - part 1」這邊的這張圖了解發生了什麼事情:

最低的地方會是左右聲道混在一起的 L+R 的單聲道訊號,這個方式可以讓很早期不支援兩聲道 (立體聲) 的 FM 收音機還是可以正常收聽,也剛好是 rtl_fm 時用到的地方。

而接下來是 19kHz 表示支援立體聲的訊號,然後從 23~53kHZ 的地方是 L-R 的訊號,最後面是 RDS 資料。

所以要把這包東西轉成 L 與 R 不是單純抽兩段 source 出來就解決了,而是需要在頻域上運算。

接著就是找看看有沒有已經做完的工具可以從 SDR source 運算然後播放,就找到 LuaRadio 這個專案,依照他的要求安裝 dependency,然後就可以直接跑了:

./luaradio examples/rtlsdr_wbfm_stereo.lua 107700000

在「rtlsdr_wbfm_stereo.lua」這頁的說明可以看到整個 flow 拉了很多處理。

不過在我的桌機上面,他會跳出三個 gnuplot 的視窗一直搶 window focus,要終止的話得按住 Ctrl-C 不放,然後點 terminal 想辦法讓 terminal 收到 Ctrl-C 才能停掉,看起來應該是 bug...

從 code 裡面可以看到他會偵測是否有 DISPLAY 這個環境變數來決定要怎麼做,所以本來以為改掉 DISPLAY 就可以了:

DISPLAY= ./luaradio examples/rtlsdr_wbfm_stereo.lua 107700000

不過看起來會卡住,還是得直接把相關的 code 都註解掉才行。

anyway,從官方給的圖可以看到整個收到的頻譜,以及 L+R 與 L-R 的樣子,也可以看到 19kHz 那邊有根訊號表示這是兩聲道:

這樣至少是有軟體可以聽立體聲了...

用 Astrometa DVB-T2 收數位無線電視台 (DVB-T)

以前用的 USB 電視棒壞掉了,去網拍上找了一隻新的來用,翻了一下跟 LinuxTVWiki 上的 Astrometa DVB-T2 這頁的圖片一樣 (2014 版本的圖):

先講一下重點,如果你買到的 USB 電視棒跟我一樣,應該可以看到兩個 source 可以收 DVB-T,而這兩個 source 都可以測試看看,在我家裡測試 Sony CXD2837ER 的收訊明顯好很多:

另外順便一提無關緊要的事情,本來在查資料的時候以為是 2013 的古董版本,但研究了一會兒發現 2013 版的「DVBT2」字比較大,所以不是 2013 版的:

插入到 Ubuntu 的時候可以看到幾個有趣的東西:

[Sat Dec 30 11:59:49 2023] usb 1-6.3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[Sat Dec 30 11:59:49 2023] dvbdev: dvb_create_media_entity: media entity 'Realtek RTL2832 (DVB-T)' registered.
[Sat Dec 30 11:59:49 2023] usb 1-6.3: DVB: registering adapter 0 frontend 1 (Sony CXD2837ER DVB-T/T2/C demodulator)...
[Sat Dec 30 11:59:49 2023] dvbdev: dvb_create_media_entity: media entity 'Sony CXD2837ER DVB-T/T2/C demodulator' registered.

意外的發現有兩個支援 DVB-T 的晶片,首先是 Realtek RTL2832 有被抓到,然後被註冊到 /dev/dvb/adapter0/frontend0 這邊。

Realtek 官網上只翻到了 RTL2832U 的資料,裡面比較有趣的是支援了 ISDB-T,不過如果在日本的話還需要 B-CAS 才能解:

Includes ISDB-T(SBTVD-T) 1-Seg

另外 RTL2832U 也支援 FM:

Includes Radio Support (FM/DAB/DAB+)

而第二個的 Sony CXD2837ER 被註冊到 /dev/dvb/adapter0/frontend1 這邊,另外在 LinuxTVWiki 可以看到 CXD2837ER 只被用在了 2018 版本,而且在外觀的部分提到了「or same as 2014 or 2017 revision」,所以看起來手上的版本應該是 2018 版的,但是殼長得跟舊的一樣。

翻了 Sony CXD2837ER 的 datasheet,可以看到支援 DVB-{T2,T,C}:

The Sony CXD2837ER is a combined DVB-T2 (incl.T2-Lite), DVB-T and DVB-C demodulator

看起來是為了 DVB-T2 而放進來的?不過台灣目前還是用 DVB-T 就是了。

Anyway,目前用起來唯一的缺點是看電視的時候同時跑 dvb-fe-tool --femon -f 1 會造成畫面破格,這點要再看看怎麼解決,不過不是大問題...

Ship of Theseus 條目的趣事

Hacker News Daily 上看到「0% of the phrases of the original Wikipedia "Ship of Theseus" article remain (twitter.com/depthsofwiki)」這篇,引用的是這則 tweet:

一開始掃過「Ship of Theseus」這個條目還沒有感覺,想偷懶發現有中文版的條目「忒修斯之船」:

1世紀時的希臘作家普魯塔克提出了這個問題:如果忒修斯的船上的木頭逐漸被替換,直到所有的木頭都不是原來的木頭,那這艘船還是原來的那艘船嗎?這類問題現在被稱做「忒修斯之船」。

回到原來的 tweet 上看才笑了出來。

另外補充一下,「」這個字念「特」,應該會有人想查,這邊附上連結。