ヾノ*>ㅅ<)ノシ帳

ノンジャンルのふりーだむなブログです。日本で10人ぐらいに需要があるネタを書くのが目標☆

Speaker Deckにまつわる実験

初回のアップロード

f:id:katc:20171031051947p:plain

変更した同名のファイルを再アップ

URLは変わらない

f:id:katc:20171031052350p:plain

変更かつファイル名を変更したファイルを再アップ

URLは変わらない

  • ファイル名→upload-test-C.pdf

f:id:katc:20171031052723p:plain

説明文を変更

URLは変わらない

  • 説明文→説明文Y

タイトルを変更

URLが変わった


青の部屋、赤の部屋、緑の部屋を思い出しますね~。赤の部屋はプロジェクターのところで当たり判定が厳しすぎて諦めましたわ。

nagoya.bin(名古屋低レイヤー勉強会)の第1回に参加しましたヾノ*>ㅅ<)ノシ

2017年10月29日(日)に開催されたnagoya.binという低レイヤーな勉強会に参加しました。この日のために肉体改造と2 kg減量しました。その程度の減量って意味あるのと思うかもしれませんが、「肉体改造」が肝です。この話は別の機会に書きます。

nagoyabin.connpass.com

正装した友利奈緒として、シンボリック実行エンジンを自作した話をしました。資料はSpeakerDeckに上げてあります。 参加してない方も宿題やっていいですからね。

speakerdeck.com

https://speakerdeck.com/katc/bainarimeng-efalsebi-nu-gasinboritukushi-xing-nilian-zhao-sitemasuga-zhi-yue-nitiao-muyou-qi-nabiao-qing-gazui-gao-desu-1

発表者は分かるが、発表内容はわからない、統一的なテーマも無い、そんな謎の勉強会にも関わらず、初心者を脱した専門技能をもった方々が集まっていました。 これぐらいは分かっててくれへんと10分に収まらんがなってとこはカットしましたが、そこそこ言いたかったことは伝わってた感じがしました。 互いの専門性の共集合は無いけど、それは大学でもやったなーってのが多かったので、個々の発表内容がすんなり入ってきました。

会場はMisocaさんのセミナールームでした。ありがとうございました。 マイク無しで声通るかな?しかもマスクしてるんに、と思いましたけど、奥行きが狭いので声を張らずとも声は届いていたと思います。 勉強会会場としてありっすね。投写も16:9オッケーみたいですし。そろそろ16:9で作るようにしたいね~。


描き下ろしたイラストです:

www.pixiv.net

裏話をすると、このネタを作るためのプログラミング作業が10時間だったのに対して、イラストを描く時間が30時間ほど、スライドを100回以上修正するのに10時間ほどかけました。 このコストの高さは、趣味でやってるからできることっすね。大事にしていきたいです。

こうした規格を外れた創作活動は今後強化していきたいと思います。 皆さんの反応と自分のモチベーション次第では(3)がリリースされるかもしれません。 (2)はプロットができているので時間がとれるかどうかです…。 〈ダイジェスト版〉ってことはDay 3以降を含めた同人誌向けのノーカット版があるのかと思った方は鋭いです。それはノーコメントです。


太ももがまだ太いので筋トレは続けます!

VirtualBoxのWindows 10 VMに外付けHDDをマウントするのが大変だった

VirtualBoxのバージョンは5.1.128です。

Windows 10のVMNTFSフォーマットされた外付けHDDをマウントするのが大変だったので解決手順を残しておきます。

USBデバイスを有効にするために、VirtualBox Extension Packをインストール
https://www.virtualbox.org/wiki/Downloads

この段階ではWindowsのデバイスマネージャでは身元不明のHDDとして認識されます。

次に、VMを一旦シャットダウンして、[設定] - [USB]の画面で、USB 2.0 (EHCI) コントローラを選択。

f:id:katc:20170927030550p:plain

これでマウントできるようになります。

研究生活に役立つDocker入門

f:id:katc:20171031062207p:plain

※走り書きです。

Dockerとは?+注意書き

Linux限定で書いてしまうが、WindowsmacOSでも利用可能

超軽量のコンテナ型仮想化を実現するOSSソフトウェア。VMのイメージで扱うと大変危険。 コンテナはシステムの資源を間借できる高機能chroot環境と思うのが吉。

Dockerでは、Linuxカーネルをホストとコンテナで共有する。これはコンテナがLinuxカーネルの機能で実現されているからである。 コンテナの中から見えるファイルシステムは厳密に独立していないので、/bootとかは触ってはだめ(/etcはOK)。 systemd(pid 1系)は使えないので気をつけて。 先述の注意点がクリティカルな場合は素直にVagrantなりVirtualBoxなり使うのが賢明。

Dockerがなぜ研究生活向けなのか?

研究室で受け継がれるVMイメージはときに邪悪である。 OSのインストールは良いとして、その後に何をどうビルドしてインストールしたのかが全く明らかではない。 別にドキュメントを用意することが必要になってしまう。 また起動と実行のためにCPUとメモリを多く奪われてしまうのは全くイケてない。

Dockerを使って研究を進められる環境を作ると次のようなメリットがある。

  • Dockerfile(後述)がそのまま環境構築手順書になる
  • 起動が速く、ホストとシームレスにつながる(※ホストPCがLinuxの場合に限る)
  • Dockerfileをgitなどでバージョン管理すると、いついつのときのコンテナを起動することができる(※image(後述)をビルドする時に細工が必要)
    • システム変更を記録に残す癖がついて良い
  • コンテナ起動後にした変更が破棄されるので、同じコンテナを使っている限り、システム側が原因で「前まで使えたのになぜか使えなくなった」が起こり得ない
    • 試しにいじって上手く行ったらDockerfileに反映するアプローチも良し

ただし、以下のデメリットもあるので注意が必要。

  • ウインドウマネージャの恩恵を受けられない(が、GUIアプリの画面を出すことは可能)
  • 複数のターミナルを出すのがサーバーと同じくらい少し大変(が、こんなのは慣れの問題)
  • Dockerfileを変更してコンテナを更新するまでに大変時間がかかることがある(変更方法に依存するが、覚悟が必要)
  • Dockerfile作成にあまりネットで言及されないコツが必要(後述)

インストール方法

Ubuntuは以下の記事で良いと思われる。 [Docker] ubuntu 14.04/16.04にDockerをインストール - Qiita

Arch Linuxの場合は、

sudo pacman -S docker
### 自分にdockerグループを追加
sudo usermod -aG docker `whoami`
### dockerを自動起動
sudo systemctl enable docker

ここで完了させておくことは、

  • dockerのインストール
  • ユーザーにdockerグループを追加
  • dockerデーモンの有効化(ないしは sudo docker daemonLinuxが起動する度に手動実行)

である。

コンテナ起動

コンテナ起動時に実行するプログラムを指定する。通常はbashを起動する。 後述するDockerfileにCMDとして起動するプログラムを明示していないケース/誤ったCMDの指定がされることがあるので気をつけること。 Dockerfileを信頼せず、コマンドラインで明示するのが安全である。

コンテナ起動のコマンドは次の通り:

### ubuntu 14.04の場合
### オプションは "run it" で覚えるのがおすすめ
docker run -it ubuntu:14.04 bash
#### runの前に `docker pull ubuntu:14.04` が必要かも
### プロセス終了時にコンテナを破棄したいとき(--rm)
### オプションは "run, remove it" で覚えるのがおすすめ
docker run --rm -it ubuntu:14.04 bash

動作確認のために上記コマンドを実行してUbuntubashシェルが出ることを確認してほしい。 ネットワークからimageがダウンロードされるので初回の起動は時間がかかる。 imageとはコンテナを起動する種になるものである。 これは次節で説明する。

高度なコンテナ起動オプションとDockerあるあるについては後半で述べる。

imageの作成

imageはコンテナ起動の元になる「種」のようなものである。 imageの作成は2通りの方法がある。

Dockerhub   Dockerfile
   |            |
  pull        build
   |            |
 [      image      ]
          |
         run
          |
 [    container    ]

1つ目はDockerhubからpullする方法である。あまり使わないので説明は省略。気になる人は「docker pull dockerhub」でググって。

2つ目はDockerfileからbuildする方法である。 Dockerfileはこの名前で存在するファイルである。 Dockerfileがあるディレクトリまで移動(cd)して、

docker build -t IMAGE_NAME . # IMAGE_NAME must be lowercase
### or
docker build -t IMAGE_NAME -f DOCKERFILE_PATH
### without cache
docker build -t IMAGE_NAME . --no-cache=true

のどれかの形式で実行すると良い。IMAGE_NAMEは制約があるので小文字でいい感じに付けると良い。 buildはキャッシュを使ってされる。apt updateで不都合が起こる時はこのオプションを付けるとよい。

Dockerfileの構成

大抵の場合上の行から、

  • FROM(必ず1番上に書くこと)
  • MAINTANER(省略可)
  • RUN または ADD または ENV または WORKDIR または USER(これが複数行続く)
  • CMD または ENTRYPOINT (省略可;1行のみ)

の順に書かれている。

FROM

FROMはベースとなるimageを指定する。何も考えずに

FROM ubuntu:16.04

FROM ubuntu:14.04

と書くといい。

MAINTANER

メンテナーの情報を書く欄。自由に

RUN

ベースのimageで実行するコマンドを書く。複数行に分けたい時は行末に「半角スペース+バックスラッシュ」

例えば、

RUN sed -i.bak -e "s%http://archive.ubuntu.com/ubuntu/%http://ftp.iij.ad.jp/pub/linux/ubuntu/archive/%g" /etc/apt/sources.list && \
    apt update && \
    apt install -y git automake pkg-config libssl-dev
RUN apt install -y curl wget bash-completion net-tools strace silversearcher-ag mlocate vim 

シェルスクリプトの要領でガリガリ書いていく。コマンドはroot権限で実行されるのでsudoは付けなくて良い。 ちなみにRUNごとにキャッシュが生成される。

1つ前のRUNでcdして、次のRUNでそこの場所でコマンドを実行はできない。RUNごとにカレントディレクトリがリセットする。 cdのし忘れには気をつけよう。面倒な時は後述のWORKDIRが便利。

ADD

外部ファイルをimageに追加するコマンド。Dockerfileから見た相対パスで書く。 パッチファイルを取り込みたいときに便利。

ADD ./my-awesome.patch /home/docker
ADD ./my-awesome.patch $PATCH_FILE_DIR

面倒でなければENVで設定した環境変数を使うようにしてください

ENV

docker buildで有効な環境変数を設定するコマンド。$HOMEを変更するときはWORKDIRを使わないとだめ。 以下例。

ENV PATCH_FILE_DIR /home/docker/projects/qemu/patches

WORKDIR

カレントディレクトリを変更するコマンド。 以下例。

WORKDIR /home/docker/projects

これをするとその後のRUNから/home/docker/projectsがカレントディレクトリになる。

USER

コマンドの実行主を変更するコマンド。このときユーザーが自動的に作成されるかは知りません。

USER docker

CMD, ENTRYPOINT

両方は使えなかったはず。複数回もできなかったはず。 コンテナが起動したときに自動実行するコマンドを指定できる。 どっちかが、コマンドラインで指定したコマンドに置き換えられるはず。

Dockerfileのトラブルシューティングのコツ

  • 前もって別の環境で実行して、このコマンドで上手くいくことを確認する
  • apt updateを冒頭で必ずする
  • ファイルがあることを確認するために RUN ls * する
  • buildメッセージに載っているキャッシュされたimageのIDを控える→ docker run --rm -it CACHE_IMAGE_ID してインタラクティブに確認【一番オススメ】
  • RUNの単位を細かくする。&&で頑張って繋げない
  • RUNで複数実行するときは ; でなく && でコマンドをつなげる

日頃気をつけること

  • システムに残したい変更をしたら、そのときに実行したコマンドをDockerfileに残すのを忘れないこと。

高度なdocker run

privillegedオプション

Dockerのコンテナは触れるシステム資源が制限されている。 USBはこれに該当する。USBを使えるようにする前提で説明する。

まず Dockerfile 後半に以下の行を追記する必要がある。

VOLUME /dev/bus/usb:/dev/bus/usb

これは、ホストとコンテナの間でUSBを共有する設定。

privilegedモードでの起動は

docker run --rm -it --privileged IMAGE_NAME[:tag] bash 

特権が付いているかどうかは次のように確認できる。

コンテナの外から:

docker inspect --format='{{.HostConfig.Privileged}}' CONTAINER_ID

コンテナの中から:

ip link add dummy0 type dummy

デタッチしたコンテナを復活させる

--rmを付けずにdocker runした場合のみ。

docker run で起動したbashをexitしたとき、コンテナはdocker ps(※起動中のコンテナを確認するコマンド)には表示されなくなる。 次の手順でコンテナIDを取得し、re-attachすることができる。

### check container name or ID
docker ps -a
### wakeup contianer with its id or its name
docker start CONTAINER_ID/CONTAINER_NAME
### you can check your container restarted
docker ps
### now you can re-attach to it
docker attach CONTAINER_ID/CONTAINER_NAME
# hit ENTER

docker attachしたターミナルで、アタッチ後にEnterを押さないとプロンプトが返らないことがある。

ショート版の手順がこちら:

docker ps -a
docker attach `docker start CONTAINER_ID/CONTAINER_NAME`

tmux

シェルが1つしかないのは不便なので、tmuxのようなターミナルマルチプレクサを使うとシェルをいくつも開けて便利。

VirtualBoxみたいにファイル共有(フォルダ共有)したい

起動時に「-v マウント元(ホスト上のパス):マウント先(コンテナ上のパス)」のオプションを与える。 -v A:B -v C:D の感じで複数並べることも可能

### read-write mode
docker -it -v VOLUME_NAME:/home/guest
docker -it -v `pwd`/HOST_DIR_NAME:/home/guest
### read-only mode
docker -it -v VOLUME_NAME:/home/guest:ro
docker -it -v `pwd`/HOST_DIR_NAME:/home/guest:ro

高度なdocker build

docker build を一々叩くのは面倒なので ./build.sh なり、ビルド用のシェルスクリプトを用意すると便利である。 docker buildに成功したらタグを付けるようにしたほうがいい。タグ名はちゃんと管理できる自信があるならバージョン番号でも良いし、 gitのコミットハッシュでもよい。後者を前提とした build.sh のテンプレートが以下:

count_x_files()
{
    COUNT=$(git status --porcelain | grep -v "/patch/" | grep $1 | wc -l)
    echo $COUNT # return $COUNT
}

IMAGE="my-ubuntu"

docker build -t $IMAGE . || (echo "[!] ERROR: docker build. exit" ; exit)
echo "[*] DONE: docker build"

if [ $(count_x_files "MM") -ne "0" ]; then
    echo "[!] There's not staged changes. git add it now"; exit
fi
if [ $(count_x_files "??") -ne "0" ]; then
    echo "[!] There's untracked patch files. git add it now"; exit
fi
docker tag $IMAGE $IMAGE:$(git rev-parse --short HEAD)
echo "[*] DONE: docker tag"

このテンプレはgit add -u && git commit のし忘れを指摘してくれる。

Dockerあるあると小ネタ

コンテナーのIDを知りたい

docker ps 

(docker buildで作成された)特定のコンテナのログを見たい

docker log CONTAINER_ID

ID は docker build のログ Running in dc043f01ca19 から dc043f01ca19 を拾ってくる

imageの一覧を見たい

docker images

イメージを消したい

### remove specific image
docker rmi IMAGE_NAME [IMAGE_NAME ...]
### force remove 
docker rmi -f IMAGE_NAME [IMAGE_NAME ...]

イメージ名を改名したい

### copy
docker tag OLD_IMAGE_NAME OLD_IMAGE_NAME
### and remove
docker rmi OLD_IMAGE_NAME

停止したコンテナだけ一覧で出したい

docker ps --filter "status=exited"

使ってないコンテナ(exitしたコンテナ)を消したい

docker rm `docker ps --filter "status=exited" -q`
### or
docker rm $(docker ps -a -q) 

タグがついてないimageを消したい (like <none>:<none>)

docker rmi $(docker images | egrep "^<none>" | awk '{print $3}')

Wi-Fiが突然死んだと思いきやwpa_supplicantのロードエラーが原因だった

当方の環境はArch Linuxです。カーネルバージョンはこちら:

K_atc% uname -a
Linux K_atc 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux

PCを起動したらWi-Fi(wlp3s0)がunavailableで死んでいました。

K_atc% nmcli d
デバイス         タイプ    状態      接続            
br-7dd2d35de895  bridge    接続済み  br-7dd2d35de895 
docker0          bridge    接続済み  docker0         
enp0s26u1u2      ethernet  接続済み  有線接続 1      
enp0s25          ethernet  利用不可  --              
wlp3s0           wifi      利用不可  --              
lo               loopback  管理無し  -- 

ググっても同じ現象の人は居ませんでした。一日悩んだら原因が分かりました。 journalctl -u NetworkManagerでNetworkManagerのログをよく見るとwpa_supplicantでエラーが出ていることが分かりました。

K_atc% journalctl -u NetworkManager | tail -20
Sep 03 19:55:53 K_atc NetworkManager[1920]: <info>  [1504436153.0566] manager: NetworkManager state is now CONNECTED_GLOBAL
Sep 03 19:56:16 K_atc NetworkManager[1920]: <warn>  [1504436176.2134] supplicant: failed to acquire wpa_supplicant proxy: Wi-Fi and 802.1x will not be available (fi.w1.wpa_supplicant1 を StartServiceByName で呼び出そうとしてエラー: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'fi.w1.wpa_supplicant1': timed out)
... snipped ...
Sep 03 20:27:38 K_atc NetworkManager[1920]: <info>  [1504438058.5537] manager: rfkill: WiFi now disabled by radio killswitch
Sep 03 20:27:39 K_atc NetworkManager[1920]: <info>  [1504438059.5157] manager: rfkill: WiFi now enabled by radio killswitch

上と同様にwpa_supplicantのログを確認しました。libssl.so.1.0.0が見つからなかったために静かに死んでしまったようです。

K_atc% systemctl status wpa_supplicant
● wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled; vendor 
   Active: failed (Result: exit-code) since Sun 2017-09-03 19:55:51 JST; 42min ago
  Process: 1927 ExecStart=/usr/bin/wpa_supplicant -u (code=exited, status=127)
 Main PID: 1927 (code=exited, status=127)
      CPU: 961us

Sep 03 19:55:51 K_atc systemd[1]: Starting WPA supplicant...
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Main process exited, code=
Sep 03 19:55:51 K_atc wpa_supplicant[1927]: /usr/bin/wpa_supplicant: error while loa
Sep 03 19:55:51 K_atc systemd[1]: Failed to start WPA supplicant.
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Unit entered failed state.
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Failed with result 'exit-c

openssl-1.0パッケージを入れてあげれば解決します。以下手順:

K_atc% sudo pacman -S openssl-1.0
K_atc% ls /usr/lib/libssl*
/usr/lib/libssl.so        /usr/lib/libssl.so.1.1
/usr/lib/libssl.so.1.0.0  /usr/lib/libssl3.so
K_atc% sudo systemctl start wpa_supplicant  
[sudo] katc のパスワード:
K_atc% sudo systemctl restart NetworkManager
K_atc% nmcli d
デバイス         タイプ    状態              接続            
br-7dd2d35de895  bridge    接続済み          br-7dd2d35de895 
docker0          bridge    接続済み          docker0         
enp0s26u1u2      ethernet  接続済み          有線接続 1      
wlp3s0           wifi      接続中(設定中)  Buffalo-G-****
enp0s25          ethernet  利用不可          --              
lo               loopback  管理無し          --   

はい勝ち〜

3000~5000円台の最近のイヤホンでオススメなやつ

タイトルの「最近の」は発売日が「最近」ではなく、「最近」の売り場で置かれているを意味します。

僕は高いイヤホンを大学で無くした経験があるので、普段は安いイヤホンを持ち歩いています。 先週耳に入れる部分の蓋が取れるといういつもの壊れ方をしたので、新しいものを探しにビックカメラへ行きました。 (ポイントで払おうと思いきや、カードを持ってくるのを忘れたので買わずに帰って来ました。e-イヤホン行けばよかったですかね…)

3000~5000円台のイヤホンはこのような特徴があります:

  • 大体のイヤホンは高音が刺さる
  • 大体のイヤホンは音がザラザラしている(僕はこれを「イヤホン(デジタル)な鳴り方」と評したい。これの逆は「スピーカー的(アナログ)な鳴り方」)
  • 音場(音の広がり)は左右の耳へ直線的でつながる感じで、広がりはあまりない。音場が広いものはあるっちゃある
  • 低音が高音より鳴る。中音域の再生能力が弱い
  • 高音が歪んでいるか攻撃的(具体的に言うと、例えばシンバルの音がぶっ壊れてる)

そんな中で6000円~9000円クラスの鳴り方をするイヤホンがあって面白い価格帯であります。

リファレンス音源は、

  • 高音テスト用:Hesitation Snow
  • 低音・高音同時テスト用:ユーロビートから適当にチョイス
  • 低音テスト用:Forever Young
  • 全体のバランス確認用:Won(3)Chu KissMe!, ワガママMIRROR HEART

です。EurobeatJ-EURO系が中心なので、人によってはこれがおすすめ?と感じる可能性があります。 プレイヤー(DAP)はCOWONのPlenue Dです。BEE+ありです。

個人的には、この価格帯で選ぶなら、解像度は重視せずに、高音が刺さらない、スピーカー的な鳴り方をするイヤホンを選ぶのがおすすめです。

final audio / E3000(5000円;おすすめ度★★★★)

final E3000 FI-E3DSS

final E3000 FI-E3DSS

ステンレス筐体。クラシック系・ストリングス系の楽曲がおすすめとポップが出ていたが、Adagio IIの再生能力を包含しているため、ユーロビート・アニソンの再生をそつなくこなしてくれる。 全音域のバランスが良く、音はスピーカー的ないしは金属的な鳴り方。高音の刺さりはなく、聞き心地良い高音を楽しむことができる。 Y23とどっちがいいのかで好みが別れると思います。

同系統の音で、2年以上前の同価格帯のイヤホンにSonyの MDR-EX650があります。それよりは心地よい鳴り方をします。音質はどっこいどっこいですかね。

final audio / Adagio II(4000円;おすすめ度★★★)

final audio design Adagio II ダイナミック型イヤホン(クリーム) FI-AD2DCR

final audio design Adagio II ダイナミック型イヤホン(クリーム) FI-AD2DCR

アルミニウム筐体。J-POP・クラブの楽曲と相性がよいというポップが出ていた。 高音の主張が弱く、どこかイヤホンな鳴り方をしてしまう面があり、もうひと頑張りを期待したくなる。 予算を4000円にするなら購入に踏み切るライン。 +1000円でE3000のレベルになるなのでそこは慎重になってもいいかも。

AKG / Y23(4000円;おすすめ度★★★)

AKG Y23BLK(ブラック)【ウルトラスモール・カナルイヤホン】 | イヤホン・ヘッドホン専門店e☆イヤホン

Y20と同傾向。こっちの方が音がよくて、艶があると感じた。

AKG / Y20(3000円;おすすめ度★★)

AKG Y23 イヤホン カナル型 ブラック Y23BLK 【国内正規品】

AKG Y23 イヤホン カナル型 ブラック Y23BLK 【国内正規品】

解像度は高め。少しAKGらしい開放的な音。少し聞き疲れする。Adagio IIの方が開放的でオススメ。

Pioneer / SE-CH5T(4000円;おすすめ度:★★★)

ねっとりした低音。音場広め。価格帯に見合った解像度。音場広め。マイルドな音。

Philips / SHE9730(4000円;おすすめ度:★)

PHILIPS SHE9730 イヤホン カナル型 ハイレゾ対応 ブラック SHE9730BK 【国内正規品】

PHILIPS SHE9730 イヤホン カナル型 ハイレゾ対応 ブラック SHE9730BK 【国内正規品】

イヤホンな鳴り方。解像度は高い。音場広め。聞き疲れする。高音が刺さり気味。

後日談【2017/9/3追記】

final audioのE3000をビックカメラで買いました。在庫切れだったのでお取り寄せでの対応となりました。それでも2営業日で届くレベルです。5000円台とは思えない音質で最高です〜

後日談【2017/9/9追記】

E3000万歳って感じになってしまっているので欠点を書いていきます。

  • 鼓膜に近い位置で鳴っているためか、音量を上げると耳が痛くなりやすい(PLENUE Dだと45/100ぐらいが限界)
  • 音場が同価格帯のイヤホンに比べて狭い
  • セミオープンなので後方の開口部から音漏れする