fireattack

直播平台Stagecrowd的画质问题

Stagecrowd（下称：SC）是大网络直播时代索尼赶鸭子上架搞的第一方直播平台。各个地方都透出一股草班台子的味道，比如不同直播的账号不互通等等，这里按下不表，专门来黑一下画质问题。

Go for a Sail STUDIO LIVE

第一次用SC是看8月的“LAWSON presents TrySail 5th Anniversary Go for a Sail STUDIO LIVE”。当然，这个活动本身就是音雨骗钱登峰造极之作，下面简单罗列下：

  1. 分割放送上下part，而且事先不公布，硬是在part1播完后才说还有part2。
  2. 每个part都有两个aftertalk，预购只能看aftertalk1，需要专门购买回放门票（“見逃し配信チケット”）才能看（且只能看）aftertalk2。
  3. 播放前有个所谓的“直前talk”，只有预购并且直播才能看到，timeshift没有。（但是，由于他们弱智，part1的timeshift其实并没有剪掉，是可以看到直前talk的233。在part2里修复了这个“bug”。）

这玩意的复杂程度之高，官方甚至“很贴心地”专门准备了个表格来罗列不同票的情况。总之，要看到所有内容，你需要付3800*4+手续费差不多小两万。

另外，官方还在B站进行了转播。票价便宜得多倒是无所谓，但是在回放时，居然事先无预告的突然包含了aftertalk2，让刚交了4000的我和吃了苍蝇一样恶心（甚至没忍住去动态喷了一波）。

不过搞笑的是，放part2的时候（只有录播，part1时延迟半小时突击加的字幕由于太差闹了大笑话，估计不敢了），虽然官方说明依然是是包含aftertalk2，但是实际并没有（不过好像也没有任何人发现的样子）。另外也没有直前talk。总之算是有点心理安慰……

呃跑题了，让我们来继续说画质。这个活动是直播talk+播片的形式，客观来讲直播部分的画质还是不错的，码率够。

但是播片的部分（正片）画质奇差，码率低全屏马赛克不提，最重要的是颜色完全错误，整个画面偏深，这点和B站版的片源一比就可以很明显看出：

SC直播版
B站直播版

注意这里还仅仅是B站直播的720P版，在回放时升级成1080P画质会更好一些。不过，这个我怀疑不是SC的问题，是片源没提供对（反正你们都是索尼一起骂了吧），因为在Part2没有这个颜色问题。更吊诡的是我搞不懂这个画质是怎么搞出来的，一开始以为是缺了一次TV/PC色域伸张，但是研究了下发现并不是，不懂了不懂了，反正有BD，不纠结。

另外一个问题就是timeshift（archive）的画质差异问题了。一般而言，这类平台的timeshift有很多种情况，有的就是把直播的源直接再摆出来（比较常见），也有回放重新压制的——由于没有串流的严格要求，回放可以码率、压制参数更高一点。当然，这里有个重要的前提，就是你得用的是更“raw”的源来压制才有意义，否则直接把直播的视频流二压一遍，不管用多高的参数，画质只可能劣化。比如YouTube的回放就是这样，经过服务器转换过一次后，画质只会变差（之前虾泥的感谢祭直播，甚至出现了回放视频比例变扁的搞笑现象）。

SC这里，很不幸地就属于后者。根据前面描述的商法，可以知道有三个视频档：直播，直播的archive，“見逃し配信チケット”进的录播。由于每个都有剪辑的需求（直播的archive不包含直前talk，录播版不包括直前talk且aftertalk从1换成了2），所以内容是不一样的。这里我是不清楚SC是在线提供粗剪功能还是线下剪好再上传（大概率是后者），无论如何，事实就是每个版本的视频画质都有肉眼可见的下降，估计是直接用直播流剪辑二压的：

直播版
直播的archive
見逃し配信チケット

这里截取了正片前的短暂talk（不是直前talk），也就是三个片源都有的部分来对比。当然介于不同视频关键帧不一定一样，这样随便选一帧对比不是100%科学，但是看衣服的纹理也可以看出二压有多过分了：

花纹逐渐消失

再补个B站版对比。虽然加了一次硬字幕，但是画质几乎和SC直播版一致，赞一下。

B站版

哦对了，码率方面SC的直播、录播都是4Mbps左右，当然这个数据本身没啥意义，颜色都不对、或者你播片的片子本身都糊成一坨了nominal码率再高有啥用呢。

TrySailのMusicRainbow07

时间来到前几天，这次观看的是MR07，播片（非生放送）。直播观看其实感觉画质还好，有点欠码但是没大问题。于是让我们来看看archive版。

这次和上次不同，archive版是个单独的片源，而且码率有提升（直播：4Mbps，archive：7Mbps）。但是，又出了新的乌龙：颜色又㕛叒叕错了。先上对比：

直播版
Archive版

如果对比细节，会发现archive版画质确实略微有所提升，但是这个颜色是怎么回事？为什么又变深了？还好，这次的原因很简单：两者错了一次gamma——一个是gamma1.8，一个是gamma2.2的效果（至于为啥是这俩数字，一个是Mac一个是PC，具体自己看维基）。如果要修复，只要把后者加个1.22 （2.2/1.8）即可还原成和前者一样的效果（不同软件对gamma或者gamma correction的定义不同，有的软件可能需要用倒数。这里是指PS色阶gamma改 1.22）：

PS修改gamma方式 很多播放器也提供播放时修改gamma的功能

但是我们怎么知道哪个是正确的呢？毕竟有的人可能会觉得反而是上面的太亮。这就需要客观对比了。在转场画面，会出现本次活动的logo：

  • 直播版
  • 回放版

虽然我没有找到这个logo本身的的高清大图，但是在音雨商店的banner里可以找到一个类似的大图：

我们这里只需要把七色色段部分提取出来，然后对比颜色就行了。其实都不需要进PS吸管，肉眼就可以看出明显是直播版颜色更接近这个。

以上是SC内部的颜色问题。那么和其他直播平台比如何呢？这里用Zaiko的来对比。之前就有听说Zaiko码率更高一点（5Mbps），逐帧对比的话，确实细节要多点。但是重点不在这里，而是两者的颜色又有细微的差别：

SC直播版
Zaiko版

可以看到，两者的颜色基本是一致的——但是仔细看，会发现SC版会在接近白色的地方有过爆的问题，注意右上角背景和鼻子高光。下面这帧可能更明显：

左：SC 右：Zaiko

为什么会出现这种现象？鬼知道。可以确定的是并不是错误地进行了一次色域伸张那么过分，两者的平均亮度只错了1（RGB）而已。另外也不是BT601/709的区别。我拆成YUV通道对比了下，可以看到只有U通道有较大区别：

左：SC 右：Zaiko

更搞笑的是，如果把archive版那个gamma错误的图，用PS色阶修复一下……

  • SC回放-gamma修复
  • SC直播
  • Zaiko

反而是和Zaiko版一样的正确版，而不是直播的那个过爆版（注意看手上的高光）！

（顺便Mocho这皮肤该保养了。）

这次是没办法已经买过票，以后可能尽量不会再买SC了。但是听说Zaiko不能多端登录（我自己没试过），不便于和别人拼车。

fireattack

僕だけに見える星

好久没更新，正好今天Live，fan from home（笑）也没啥事做随便写点相关杂记。

歌曲

这次两首都不错，尤其喜欢c/w的『あしあと』，瞬间可以挤进前五！Mocho的single的c/w一向很对我胃口，掐指一算甚至比主打更喜欢的次数更多点（花に赤い糸、箱庭ボーダーライン、No Distance、シュークリーム，さよなら観覧車也算和365×LOVE打平）。说实话我也不知道这种曲风叫啥（访谈是说R&B），和三森那个『アレコレ』差不多。

主打么感觉副歌部分一般，mocho对于这类高音的驾驭能力还不太行，发声方式感觉不是很符合甜美的声线。之前专辑里的『秘密のアフレイド』也有同样的问题。

MV

和上次的『今すぐに』一样，这次依然可以在Apple Music/iTunes获取1080p版。不过这次有个小插曲，我购买了之后本来想顺手塞份b站，结果被提示撞车：

结果下面那个“撞车”的链接还打不开。用biliplus的API获取了下发现是索尼音乐中国传的，挂代理看了下那个账号发现，和其他流媒体服务类似，索尼也开始在B站提供最新MV的更新了。好处是介于国内付费习惯的问题，不像Apple Music或者YouTube Premium Music，不用购买高会即可观看（只是要有大陆IP）。当时看到时候（刚更新几个小时）这个MV还只有十几的播放，毕竟用的是罗马字名字+tag，一般估计很难搜到。后来好像在圈里传开了，现在已经飙到了一千多。

画质方面，iTunes版虽然是1440×1080，但是凭借着5Mbps的码率还是在动态方面秒了B站的3M出头的版本；但是如果是静态画面，那B站版毕竟像素多还是要锐度更高一些。总之各有优缺。这里share下iTunes版。

重点批评下辣鸡YouTube Music，本来那屎一样的UI（作为音乐服务）如果不是订阅频道有推送，根本几乎无可能找到那MV（地址）；而且非日本时区好像得等到当地时间到了11日才能看（否则得挂日本代理）。最重要的是，画质非常差，码率低不谈，颜色不对，甚至比例也不对——要横向缩小到1904px才对（外面的像素？自然被它给出血掉了）。难道你也是我之前黑过的mora那样按ITU DAR瞎转换？

下面对比：

iTunes版
B站版
YouTube h264版 (注意颜色，深色部分已经有点clip)
YouTube VP9版 (只有30M，画质最可怕)
附赠DVD版：DAR已经修正。注意上下出血

MV内容没啥好点评的，很喜欢这个条纹衣服（想起kraz去年Live那个睡衣）。

封面

这次封面倒是简单，没有一万个版本，基本所有的颜色都是一致的，那只需要找个画质最好的就行了。目前看到最大的是akiba-souken的1644p（图片URL去掉t640_获得原始画质）（Amazon也是同样大小，但是压缩率极高）。

iTunes的3000px依然是upscale的，不要用（顺便吐槽，这些流媒体网站对于非正方形的封面总是很多余的加白边，在很多播放器里都巨丑，求求你们不要了好吗）。

mocho的碟似乎通常半身照/初回全身照都快成惯例了。我还是喜欢大头照，一般移动设备都用那个。

公式照

除了封面还有个同一时期拍摄的新公式照，被用在官推等大量地方。这个图的最大图同样在上面的访谈的第一页可以找到。但是，这个接近正方形的其实是剪裁版，原始长方形版可以在SonyMusicShop以及mocho SME官网看到（虽然尺寸小很多）。不幸的是这里则出现了颜色的不一致：SME官网的和别人都不一样，明显发蓝。

  • SME
    SME官网 (发蓝)
  • SMS
    SonyMusicShop (=官推)

按照经验，发蓝一般是CMYK的CMY通道错误强制当成RGB用导致的；但是我按照前文所述的方法反向了下（试了PS自带的大部分CMYK profile），色调还是差不少。右边这图也有点意思，虽然是RGB但是里面却莫名其妙的内嵌的有个“SMC_coated_CMYK2006”的CMYK的ICC文件，直接导致在我explorer没法生成略缩图（PS倒是能打开，会报个错）。这有两种解释：图片确实正确地转换成RGB了，只是ICC莫名地没去掉；或者图像其实应该是CMYK但是错误地保存成了CMYK。介于几乎所有地方都用的是这个版本，外加和其他宣传图（特典等）的色调也一致，我倾向于这图颜色本身是没有错的，只是残留了ICC而已。我也试过把这个ICC提取出来套到SME那张偏蓝的图上当做profile，没什么进展。

更新：刚写完就发现，Apple Music的公式照更新了，也是这个偏蓝的颜色；外加animate的特典似乎也是类似的颜色（明度高一些）。但是A/G的宣传卡则是和官图一致，我现在已经彻底不确定哪个才是正确的了……

fireattack

Hi-Res的意义（外一则）

（本文部分观点已经在在各种旧文中发表过，如果有既视感为正常现象。）

Hi-Res音频（相比CD）是否有意义？首先要客观分析HR到底改变了什么。

Remastering / remix

之前提过，很多时候Hi-Res最大的意义并不在于“High”本身，而是给了厂牌一次re-release的机会。这本质上和是否HR是没有任何关系的，唱片公司如果愿意，完全可以发行remastered的CD（事实上，很多精选集CD里的旧曲都进行了remaster）。注意这里的remastering是指狭义的、即混音有明显的变化的情况，从物理角度来说就是波形或频谱有明显的变化，不包括单纯的音量、动态范围变化（compress），那个下面专门叙述。

当然，重新混音并不是单纯的技术问题，而且还有艺术发挥的成分，所以这个主观性就很大了。很多时候可能重混后的版本不如原版（个人喜好）。随便举个例子，Lantis的HR版的『U・N・M・E・I ライブ』和CD版混音有较为明显的区别，HR版声场重新调整过，但是我个人觉得人声偏小，更喜好CD版。另外就是上次说过的「THE IDOLM@STER MILLION THE@TER GENERATION 11 UNION!!」这张碟也有类似区别。

对于新发行的音乐，一般CD版和HR版不会也不应该有混音（狭义）的区别——几乎不存在某波形HR能发挥、CD发挥不出来的情形。如果厂商这么做，那只能认为是为了商业考虑故意劣化CD版，而不是什么技术限制。

高采样率

一般HR都是从CD的44100Hz提升到96000Hz。由于采样定理和人耳的频率听觉极限客观摆在那里，可以自信地说，高采样率应该是HR最无用的提升没有之一。

硬要说的话，有个小问题就是现在音乐大多在制作过程中使用96000Hz（或者48000Hz？），而CD的采样率由于历史原因是44100这个不能整除的数字，所以resample可能会有时域上的aliasing等问题。不过，有大量高质量的resampling算法的存在，这个问题在主观听感上的影响可以忽略不计。

高量化精度

CD的量化精度（位深）是16bit，HR一般提升到24bit或者32bit。虽然从听感上来说这个到底能否能产生肉耳可辨的区别也很难讲，但是考虑到类比图像的话，8bit/channel这个在当年被普遍认为绰绰有余的位深现在肉眼可见的捉襟见肘（更不要提当年为了work around这个位深在深色感知灰度不足的问题，搞出的遗毒万年的gamma空间，这里按下不表），这里我们还是保守点说高位深还是大概有用的。而且高量化精度最大的优点就是给响度/振幅调整留下了足够的空间——这点在下面详述。

动态范围

前面铺垫了这么多，重头戏其实就是想说这个。CD明明是一个各种指标上都优越于黑胶的介质，为什么许多人却在追求70、80年代的老唱片，而且两者确实有明显的听感区别？一言以蔽之：万恶的响度战争。

在追求“越来越响”的前提下，导致音乐的平均音量（我们用一个简单的客观指标：RMS）不断上升，而波形的振幅极限则是固定的0 dBFS，所以能做的只有不断压缩动态范围，使得音乐越来越平（再多不再展开，参见旧文）。

响度战争在进入21世纪之后已经基本进入一个平稳期，基本商业作品（指我一般听的日本ACG）稳定在单边动态范围（RMS->Peak）9-11dB这个数字上。

眼尖的可以发现，响度战争这个问题，和CD vs HR又是没有直接关系的：你完全可以塞高动态范围（因而平均音量也要小很多）的母带进CD（严谨地说，高动态范围配合高量化精度当然最好，但是CD的位深一般也绰绰有余了），只是厂商为了听起来够响不这么做而已。

幸好，HR一般是面向所谓audiophile的，所以比较重视这个问题，不会过度压缩动态范围。而这，也几乎是任何新发行音乐唯一值得追求HR的原因。

反过来讲，如果你发行的HR和CD完全一样的动态范围、更没有mastering上的区别，仅仅是数字96/24好看，那真的有意义么？请容我大言不惭地说一句，没有！

这里让我们有请Lantis选手：

TitleVersionRMSPeakDiff
Glow MapCD-8.84-0.18.74
Glow MapHi-Res-8.83-0.18.73
あの花のようにHi-Res-9.42-0.68.81
なんどでも笑おうHi-Res-16.8016.8
眠り姫 [ORT]Hi-Res-16.33-0.0916.24

不用多说什么了吧。下面两首是作为对比的哥伦比亚的最近发行的的HR。HR和CD完全一样的动态范围就不提了，更可怕的是烂铁的CD们的RMS已经拉到了-8.x这个水平，还剩多少动态范围可想而知了。

当然这个问题不是只有烂铁一家有，只不过一般没这么夸张。看看もちょ最近几张CD（这里同时列出单曲版和专辑版，因为部分有变化）：

ArtistSgAlSongSourceVersionRMS (dB)Peak (dB)Diff (dB)
麻倉もも52365×LOVEAlbumCD-9.922-0.0289.894
麻倉もも52365×LOVESingleCD-10.847-0.00110.847
麻倉もも52365×LOVESingleHi-Res-12.595-0.19812.397
麻倉もも52365×LOVEAlbumHi-Res-11.323-0.20111.122
麻倉もも62シュークリームAlbumCD-10.388-0.00110.388
麻倉もも62シュークリームSingleCD-10.928-0.00110.927
麻倉もも62シュークリームSingleHi-Res-12.639-0.19812.442
麻倉もも62シュークリームAlbumHi-Res-11.805-0.20011.605
麻倉もも62スマッシュ・ドロップAlbumCD-9.808-0.0019.808
麻倉もも62スマッシュ・ドロップSingleCD-9.990-0.0019.990
麻倉もも62スマッシュ・ドロップSingleHi-Res-11.945-0.19811.747
麻倉もも62スマッシュ・ドロップAlbumHi-Res-11.247-0.20011.047
麻倉もも72“さよなら”聞いて。AlbumCD-10.814-0.00110.814
麻倉もも72“さよなら”聞いて。SingleCD-9.392-0.1139.279
麻倉もも72“さよなら”聞いて。SingleHi-Res-10.057-0.1169.942
麻倉もも72“さよなら”聞いて。AlbumHi-Res-12.201-0.20112.000
麻倉もも72ユメシンデレラAlbumCD-10.376-0.00910.367
麻倉もも72ユメシンデレラSingleCD-9.107-0.1748.934
麻倉もも72ユメシンデレラSingleHi-Res-9.709-0.1729.537
麻倉もも72ユメシンデレラAlbumHi-Res-11.783-0.20111.582

もちょ早期几张也存在CD版和HR版动态范围完全一样的问题，不过最近发行的至少能多出2dB左右。另外比较搞笑的是同样是音雨人，制作还有细微的差别，もちょ这里可以看到HR版一般有很多余（正确制作的音频有没有headroom，并没有任何区别）的-0.2dB的headroom，而ナンス的碟则基本全都是CD、HR无论RMS/Peak都完全一样的。手头的CD没抓只存了HR版，就不贴数据了。

不过，不同动态范围听起来区别大不大？这个和个人听力、设备、以及更重要的音乐类型还是关系比较大的（例如交响乐一般很需要大动态），我一般听听日呆流行也听不太出区别（事实上，为了车上放歌方便，我放手机的音乐全都是手动压缩过的动态范围均衡过音量的，我有罪）。但这至少是一个实打实、肉眼可见（笑）的客观的区别。

外一则：Python的音频库

在写DR计算的脚本时，发现Python的音频处理库中，似乎并没有一个明显的first choice。当然，数学计算部分都是用Numpy做的，我这里需要的仅仅是一个解码read的库而已。

搜刮了一阵，大概有这么一下几个选择，这里简单介绍下区别：

def read_wavefile(f): 
    from scipy.io import wavfile
    samplerate, data = wavfile.read(f)
    return data, samplerate

最简单的scipy里的wavfile，基本不支持wave/PCM之外的任何类型。输出就是原始整型，取决于位深，int16或者32。注意输出顺序是采样率/值，我颠倒了下便于和别的几个一致。

def read_sf(f):
    import soundfile as sf
    return sf.read(f)

SoundFile库。输出似乎永远是float64。支持的格式比上面多，但是不支持m4a（好像支持raw AAC？）。

def read_librosa(f, resampling=None):
    import librosa
    data, samplerate = librosa.load(f, sr=resampling, mono=False) #mono by default, resampling super slow
    data = np.transpose(data)
    return data, samplerate

librosa。其本质是调用SF（上述）或者audioread，所以支持的格式也有限。另外参见注释：默认是mono输出很迷惑，自带的resampling巨慢。值的矩阵要转置下和别的统一。好像永远是float32。

def read_pydub(f, normalized=True):
    import pydub
    a = pydub.AudioSegment.from_file(f)
    # a = a.set_frame_rate(44100)
    y = np.array(a.get_array_of_samples())
    if a.channels == 2:
        y = y.reshape((-1, 2))
    if normalized:
        if y.dtype == np.int16:
            power = 15 
        elif y.dtype == np.int32:
            power = 31
        else:
            raise Exception
        return np.float32(y) / 2**power, a.frame_rate # convert to float32 should be more than enough
    else:
        return y, a.frame_rate # y is same as PCM (int16 or 32)

pydub是我比较推荐使用的库了，他是调用FFMPEG来解码的，所以基本支持任何格式。可以通过set_frame_rate来resampling。唯一的问题就是他默认输出的格式和别人比较与众不同，所以要通过上面这一坨子来输出和别人一样的东西。

这里的normalized是指把PCM的整型normalize到[-1,1]的float，并不会改变振幅啦。因为我后面发现做数学计算的时候整型会比较烦，所以我直接在这里面转了float32。

题外话，int16转float [-1,1]无论是除以2^15还是2^15-1都会有小问题（前者会导致32767无法变成1，后者会导致-32768溢出，虽然业界惯例是前者），不是左右对称的辣鸡有符号整型真的超纠结……

另外一个巨坑是如何判断np.array的dtype，参见这个SO，辅助阅读这个。

最后前几天发现pydub有个bug：读取24bit的wav巨慢，比同样的FLAC慢几十倍，原因不明。

fireattack

乐天的杂志放题

本月起Amazon的Kindle Unlimited不知道为什么突然不再放声A、声G和Animedia了。本来怀疑是因为本月发行时间较早导致的未能同步更新，结果过了一周之后也没有。再加上Animage有正常放出，那就不得不怀疑是这些杂志退出了Unlimited了。虽然目前还抱有下个月观察一下的希望，不过也要先研究下别的路子。

上文有提过BW的放题服务没有声G，所以我随便浏览了下别的几家——乐天的很吸引眼球。价格低廉（月供380日元），可以PC、App阅览，而且网站做的还不错，最重要的是上述那些杂志都有。可以试用一个月，所以就先来白嫖试试。

浏览器看需要日本IP，app则不需要（仅测试安卓；app本体需要日区市场才能下载）。

其网页版默认是显示1024px的小图，直接读取（虽然我没搞明白为啥thumb的资源文件直接打不开，但是不重要没细究）；双击或者滚轮放大后自动后台读取pdf格式的原始文件然后用pdf.js加载到canvas里。阅览器是angular写的。

本来以为pdf肯定有加密毕竟下下来直接打不开。第一时间肯定是先试试改后缀名，但是改了.jpg之后我用的XnView MP还是打不开。所以我研究了N久的如何hook JS来批量下载blob（手动下载倒是直接就能下），但是也没搞明白，js框架太烦了（顺便一提，不要直接保存canvas，二压姑且不提，canvas是又根据你窗口大小缩放过一次的图。）

回家后，想先用FlexHex看下那pdf文件的header，结果发现家里用的ACDSee直接tm就把我改过后缀的图打开了……对比了下header，那个所谓的pdf好像就是在一个JPEG文件前面加了几百个Byte的伪PDF文件头，ACDSee和PS的鲁棒性都比较强直接就能读，XnView MP比较严格，没有看到JPEG的文件头就不行。简单地搜索FF D8 FF然后把前面的bytes删掉之后，就和正常的JPEG一样了。

之后又费了些功夫写了个脚本，可以直接给个网址自动下载所有图片外加后处理。中间碰到的坑是Python的requests读取到MozillaCookieJar中expiration为0的session cookie会自动无视，要手动强制改下时间。

顺便一提，其资源文件名顺序都是按左开来排序的，对于这些右开的杂志，下下来就会变成19、18、21、20这样子，还得每两页swap一下（封面封底不动）。

之前说过，之所以会选择Kindle Unlimited而不是其他一些便宜多的同类服务，纯粹是为了提取方便便于收藏。既然这个也能这么简单地下载，那确实挺让人心动了。

不过，下载方便只是一方面，重头戏自然是图像质量。由于这个可以直接下载到网站提供的“原图”，所以首先就杜绝了BW那种原始资源就是混淆过的，你重新拼起来后所以为了防止二压只能被迫存成PNG的体积注水问题。而且更可怕的是，其原图是3072px高，比Amazon的1920px和BW的20xx px都要高得多。而且分辨率是真实的，并非放大，看文字部分的锐度就很明显（上文说过，BW网页版虽然看似有2000，但是原始资源即使1:1也会发虚，有水分）。

但是！一张3000px的图只有几百K，这JPEG质量相信不用说也能猜到有多惨了——70%，4:2:0。如果仅仅是这个我觉得还能忍，因为缩到1920px之后的信息熵估计也没差到哪里去嘛，但是还有个无比纠结的颜色问题。

之前提过BW的声A和Kindle完全一样，但是声G略有偏色；结果到了这边，好像所有的杂志颜色都和Kindle不一样——颜色比起Kindle版，要深非常多（注意，和BW的偏法还不一样）。虽然单独看几乎不会觉得有啥问题，但是和Kindle比了比还是觉得Kindle好些。而且Kindle的声A的画质真的高（95%，4:4:4），这70%的JPEG缩2/3估计也打不过。声G倒是另说，Kindle版的图像虽然名义上是95%，但是有色度抽样（4:2:0）外加是用极差缩放算法缩出来的，有很明显的狗牙和JPEG artifact。

说了这么多来看几个例子。先看看声G。

先对比颜色：

  • BW
  • Kindle
  • Rakuten

（其实单独放一张图不太客观，毕竟不知道照片本身调色是什么风格。整本一起看会更准确点。）

再来看看细节：

  • BW
  • Kindle
  • Rakuten

（推荐查看原图）多了那么多分辨率，确实文字还是清晰多了。不过也能看到JPEG artifact之多。

声A我们换个比法，我把这个3000px的图缩到1920然后和Kindle版side by side对比下。

左Kindle，右Rakuten

Hmmm..好像也不是很差，而且有人估计更喜欢这颜色而嫌左边太亮？

对比完，于是我更纠结了。虽然3k的分辨率是很有吸引力，但是颜色问题果然太重要了。如果Kindle能够恢复，我还是主力收集Kindle的版本好了，这个和BW的可以当备胎。

后记：几个月后（21/01/31）终于反应过来，乐天的版本原来又是错了一个pc/mac的gamma！ps加个1.22（2.2/1.8）后立刻和其他版本一致了！

fireattack

两个Win 7 CMD的bug

短文。

这两个月内遇到的问题，虽然Win 7已经退环境了也不指望修复，但是这俩问题都是我搜了半天也几乎完全搜不到任何信息的，觉得有必要稍微记录下。

Bug 1：输入和terminal宽度相等的字符数，会莫名换行

可以用以下脚本测试：

Python：

import shutil
columns, rows = shutil.get_terminal_size(fallback=(80, 24))
print('Columns:', columns)
print('-------------------')
print('a'*(columns)) # line breaks
print('-------------------')
print('a'*(columns-1)) # works fine
print('-------------------')

Node.js：

console.log('-------------------------------start-------------------------------');
var col = process.stdout.columns;
console.log("a".repeat(col))
console.log('--------------------------------end--------------------------------');

在CMD、PowerShell甚至VS Code里调用都会出现换行bug，无论column是多少：

cmd.exe
In VS Code

这个Bug是在使用https://github.com/Last-Order/Erii这个框架时发现的。它调用了一个叫clui的库，里面有条fill()命令就是把整行用空白字符给填满（便于overwrite已有内容），结果就导致多出很多空行。

Bug 2: 用C#的Process启动cmd的bug

标题太长了写不下，这个behavior是这样的：

Process myProcess = new Process();
myProcess.StartInfo.FileName = @"cmd.exe";
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.RedirectStandardInput = true;
myProcess.StartInfo.RedirectStandardOutput = false;

myProcess.Start();
myProcess.StandardInput.WriteLine("echo test > 1.txt");

如果你用Process()来启动cmd.exe，并且重定向stdin，但是不重定向stdout，会出现以下奇怪现象：

  1. 在VS里debug时，会发现stdout也被重定向（弹出的cmd.exe里没文字），但是功能好像还基本都正常（比如上述的范例，会真的执行echo test到1.txt）。
  2. 如果编译好的程序直接双击运行，则cmd会显示一瞬间立刻crash。自然也不会执行任何你WriteLine进stdin的东西。
  3. 据说这个问题似乎只有WinForms程序会有，Console程序不会。（未测试）

这个问题其实我N年前还在用C#的时候就发现了，只不过今天碰巧又在别人写的程序里遇到（作者肯定是用Win 10的，所以没碰到）。介于这个bug在N年前Win 7还是主流的时候就有了，我寻思应该很多人问过才对；但是我找了好久，虽然找到一万个workaround，但是从来没人正式提到这个bug，直到看到这个贴（发表于2010年）。这里，作者很完整的描述了这个现象，但是很显然，依然没有人修复，仅有的几个回复也是牛头不对马嘴（顺便吐槽，这也算是网上问技术问题回答者的通病了）。