外で保管しているクロスバイクのタイヤが、だいぶ劣化してしまって不安なので交換した。バーテープも同時に交換
チューブは交換しなくてもいいかと思ったけど、タイヤに貼りついてしまってとれなかった。無理にとって再利用もこわいので予備のものに交換した。
外で保管しているクロスバイクのタイヤが、だいぶ劣化してしまって不安なので交換した。バーテープも同時に交換
チューブは交換しなくてもいいかと思ったけど、タイヤに貼りついてしまってとれなかった。無理にとって再利用もこわいので予備のものに交換した。
一応バックアップ
sudo parted -l Model: Virtio Block Device (virtblk) Disk /dev/vda: 107GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 51.5GB 51.5GB ext4 Linux filesystem 2 51.5GB 53.7GB 2145MB linux-swap(v1) Linux swap 3 53.7GB 107GB 53.7GB ext4 Linux filesystem Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 982M 0 982M 0% /dev tmpfs tmpfs 200M 24M 177M 12% /run /dev/vda1 ext4 48G 18G 28G 40% / tmpfs tmpfs 1000M 0 1000M 0% /dev/shm tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs tmpfs 1000M 0 1000M 0% /sys/fs/cgroup /dev/vda3 ext4 50G 17G 31G 36% /data tmpfs tmpfs 200M 0 200M 0% /run/user/1000 cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/vda1 during installation UUID=bec2c6ce-a9f5-4ebf-a264-065bcd55f2d4 / ext4 errors=remount-ro 0 1 # swap was on /dev/vda5 during installation UUID=8efef618-8831-4075-aae1-1d95730b25e8 none swap sw 0 0 UUID=f1304b76-c52f-41c5-9770-f8fadcf2f2d8 /data ext4 defaults 0 2 swapon -s Filename Type Size Used Priority /dev/vda2 partition 2095100 2094876 -1 sudo blkid /dev/vda3: UUID="f1304b76-c52f-41c5-9770-f8fadcf2f2d8" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="0b483f43-b168-4a48-bc64-13428db0f42b" /dev/vda2: UUID="8efef618-8831-4075-aae1-1d95730b25e8" TYPE="swap" PARTLABEL="Linux swap" PARTUUID="707f15c7-5c40-4501-949c-218fd115e7d9" /dev/vda1: UUID="bec2c6ce-a9f5-4ebf-a264-065bcd55f2d4" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="dae9a827-082d-4aad-9438-f2da8cc6f62c"
ssh cho45@stfuawsc.com -C -t 'sudo dump -0u -f - /dev/vda1' > sakura-dev-vda1.dump ssh cho45@stfuawsc.com -C -t 'sudo dump -0u -f - /dev/vda3' > sakura-dev-vda3.dump
h2o の再ビルド再インストール (libc の更新による)
perl 関係
rabitmq-server
mqtt proxy として使ってるが、再インストールして設定しなおした。
async function loadAsImage(svg) {
return new Promise((resolve, reject) => {
const svgXml = new XMLSerializer().serializeToString(svg);
const blob = new Blob([svgXml], { type: 'image/svg+xml' });
const url = URL.createObjectURL(blob);
const img = new Image();
img.onload = () => {
URL.revokeObjectURL(url);
resolve(img);
};
img.onerror = (e) => {
URL.revokeObjectURL(url);
reject(e);
};
img.src = url;
console.log(url);
});
}
const img = await loadAsImage(svg);
ctx.drawImage(img, 0, 0); XMLSerializer を使っているところ。svg.outerHTML だと HTML 的に解釈された svg なので、xmlns が入らず、単体の SVG としては正しくないものになっている。
ただ、ブラウザ自体は HTML の svg が xmlns を持っていることは知っているため、XMLSerializer を使うことで正しい svg にできる。
今まではスプールの外周で支えるタイプを使っていたけど以下の点で問題があった
ということで、スプールホルダを一新することにした。
スプールを固定するボルトとナットを作り、そこに固定軸を貫通させるようにした。
TR30x6 という台形ねじにした。早くねじこみたいと思うとピッチを広くしたくなるが、Fusion360 だとピッチが広いねじだと台形ねじになるようだった。デフォルトだと3Dプリントしたときキツいので、ねじの面をメス側で0.2mmオフセットさせている。
ところで Fusion360 だとねじの面取りがあまり直感的ではなく、先に穴に対して面取りをかけてからねじを作成し、面取りのフィーチャをねじの作成後に移動するという手順を踏まないといけない。
メス側を完全に貫通にすることで、ボルトをつけたままスプールホルダだけつけはずしできる。
ボルトをハメるだけの簡単な構造。
ボックス的にギリギリ3つのスプールが収められる感じなので、軸が干渉しないように工夫してある。軸の位置を、上下に若干ずらし斜めにすべらせて設定する構造に。
パナソニック ドラム式洗濯乾燥機 幅63.9cm 洗濯12kg/乾燥6kg 左開き NA-LX125CL-W マットホワイト トリプル自動投入 スゴ落ち泡洗浄 はやふわ乾燥 ヒートポンプ cho45
買ってから11年、これまで何度か修理してもらったり(最初の5年で2回)、自分で修理したり (排水モーター・給水弁) してきたが、買いなおすことにした。
乾燥機のファンモーター異常で乾燥が不可能になった。ファンモーターは背面パネルを開けないとアクセスできない。本体を動かせない状態で、一人で修理するのはたぶん無理。十分使っただろうということで買い替えることにした。
洗濯脱水は可能なので脱水までやって近所のコインランドリーで乾燥をかけた。コインランドリーだと乾くのがかなり早い。
メーカーはパナソニックで、NA-LX125C にした。他のメーカーも検討はした (AQUAとかTOSHIBAとか) けど、結局以下の点でパナソニックにしてしまった
機能面では洗剤自動投入ぐらい。細かい設計が変わっているのは感じる。自動投入の位置にあった制御ユニットが下にきていたり、その関係か排水経路も変わって糸くずフィルタが右に移動していた。
10年前よりも全体のサイズが若干(数cm) 小さくなっていて、より直方体に近くなっている。
白物家電はサポートの充実度からケーズデンキで買うことが多いのだけど、今回も結局ケーズデンキで買った。
最初、納期ができるだけ早いところという基準でヤマダデンキで買った。しかし蓋を開けてみれば、ウェブサイト上に表示されている納期は全然嘘で、実際の納期が2週間ぐらいだったので、ほんとひどいなと思いキャンセルした。サポート返信も遅い。
そのあとすぐ納期遅めっぽい表示のケーズデンキで買ったけど、結局ヤマダで提示された納期よりもかなり早くなった。最初からケーズデンキで頼めばよかったので、こればっかりは本当に評判悪いところで買ってはいけないという教訓だった。
https://lowreal.net/2023/05/15/3 去年書いたこれと全く同じ状況が続いている。何も状況は変わってない。SNSの悪い部分だけをしばらく感じ続けている。
特に個人的に面白いことをしているわけでもないし、趣味が充実しているかというと、趣味って何だっけ?という気持ちになる。ギターやってるだろと言われそうだけど、ギターはすごく高いモチベーションがあるというわけではなく、あまりにも他に生産的なことに取り組めないので、せめてなんらかの手は動かしておこうという感じで、楽しんで取り組んでいるかというとかなり微妙なバランスになっている。楽しんでないわけではないけど、楽しくないことも多い。
写真も撮ってないし、特に撮ろうという気持ちがでない。外に出るモチベーションがかなり低い。
そういえは結構前に Google Analytics は止めていたようだ。いつ止めたかわからない。まったく見てもいないのにサイトレスポンスを下げるのでさくっと消したようだ。
Adsense はわずかながらレンタルサーバ代になるぐらいの収益があり、サイトレスポンスへの悪影響は気になっていたものの、貧乏性すぎて消すのにずいぶん躊躇していた。しかし最近ほかのサイトの Ads by Google と書かれた広告で、かなりひどいのを見かけて、もうダメだと思った。
Adsense ではひどい広告はあまり出ないと思っていたが、そんなことはないみたい。
https://cho45.stfuawsc.com/metronome/
あいかわらず自分で書いたメトロノーム実装を使っているが、フットスイッチで操作できればなという気持ちになったので、MIDI対応をした。
Web MIDI API はオリジンごとに一括で許可/不許可を与え、一度許可すると次からは prompt なしで接続できるようだ。なので最初の一度だけセットアップ(許可)を行うと次からはページをロードするだけでMIDIメッセージは受け取れる状態になる。
細かい機能 (3連の裏をとれるようにするサポートとか) をちまちま追加したりしていて、こういう小さいツールは自分で作る喜びがあっていいなと思う。
HOTONE AMPERO II STOMP cho45
競合としては BOSS GT-1000CORE とか、LINE6 HX Stomp あたりが値段が近い。
私見
http://community.hotoneaudio.com/forum/discussionDetail?id=602
全く使えなくはないが3段階ぐらいしか可変しないので実質は使えない。
Ampero Press は 10kΩリニアカーブらしいが、FP02M は 100kΩのAカーブっぽい?
一応、本体不具合も疑って、手元の10kΩ Bカーブの普通のpotで確認したが、それだと問題なかったので、抵抗値かカーブかで相性がありそう。
18V 2A、センターマイナスのアダプタが付属するけどやたらでかい。基本的に USB PD で供給するようになんとかしている。
Hotone Ampero II STOMP は入力電圧が 9〜18Vなので、とりあえず Type-C Power Delivery のアダプタから15Vをひっぱってきて使ってみていた。特に問題はなく使えた。こうしとけば、PD 15V出せるモバイルバッテリー使えばバッテリー駆動できる。
これをするのに必要なのは
なおセンターマイナス問題はかなりうざいので、ブリッジダイオードで全波整流して極性を統一するケーブルを別途予備につくっておいている。
他のペダルと同時に使う場合、電源が一本化されていたほうが楽なので、パワーサプライを使うほうがよい。
VITAL AUDIO POWER CARRIER VA-05 MkII というパワーサプライを使っている。全ポートがアイソレート(絶縁)されている、つまりトランスが入っているタイプ。
ただ、供給電流が 9V 500mA と Ampero II STOMP が要求する 9V 800mA には足りないので、2ポートを並列にしている。絶縁電源なのでただの並列でもだいたい大丈夫なはず。
このパワーサプライは入力が 12V 2A なので、12V で PD をトリガーできる基板を利用している。12V は PD では若干特殊なので、対応していない充電器が多くてイマイチ。15V で供給したくなるが、内部の入力電解コンデンサの耐圧が16Vと余裕がなさすぎるので、素直に12Vを供給させている。
PCアプリとの通信は MIDI の SysEx で行われているようだ。
本体の DIN の MIDI IN に入ってくる MIDI メッセージは USB にもスルーしてくる。MIDI フットスイッチがある場合、Ampero に接続しておけば、Ampero の USB 接続からその MIDI メッセージも受信できる。
Ampero Control は Bluetooth / USB / DIN で MIDI メッセージを出せるフットスイッチ。かなり汎用性が高い割に価格はこの手のものだと安い (14000~18000ぐらい)。ただしアプリがないと全く設定ができない。
4つのモードがある
注意書きとして「Ampero Control のスイッチング機能は、踏んだ(押した)フットスイッチを離した時にメッセージ信号を発信します。他社製品に見られるスイッチング動作機能の設定変更はできません。」と書いてあるが、これは微妙に誤解を生むというか、実際は「押したときにメッセージを送信する」という挙動は限定的に実現できる。
というのも Momentary というモードだと、スイッチを「押したとき (A Group)」と「離したとき (B Group)」でメッセージを送信できるため、Momentary モードで A Group にだけメッセージを設定すると「スイッチを押したときにメッセージ送信」という挙動になる。Single というモードは実質、Momentary の B Group のみに登録された状態なので存在意義は謎
ただし Toggle に関しては離したときにメッセージ送信という挙動が変更できない。ただ、Toggle はフットスイッチ側に状態を持つ (モーダル) という側面があるので可能な限り使わないほうが良いと思う。
ここでいう「微妙な音ずれ」はサンプルレート48kHzで、1分あたり18サンプル(=0.4ms)のもので、普通は気になるものではない。
これは原理的になくせないずれである。
OBSで複数のUSBオーディオデバイスからの音声をマルチトラック化して録画データにくっつけている。アナログで同じ音声を入力している別々のデバイスの2つのトラックの音を細かくあわせてみると、デバイス間で徐々に広がる遅延があることに気付いた。あまり大きい量ではないが、気持ち悪いので一旦調べてみることにした。(詳しい人はこの時点でそりゃダメじゃんと思うだろうが……)
だいたい1分で18サンプル(=0.4ms)ぐらい進んでいる。2分ならもっとすすむ (数えるのが面倒だけどだいたい倍ぐらい)。
追試として、同じアナログ入力をしている2つのインターフェイスを同時にOBSで録音して、録画開始直後に同期をとり、その後の1時間ぐらい波形のずれを見た。メトロノームを鳴らして音声入力にした。
前にずれる・後ろにずれるということが起こる。ずっと一定でずれていくわけではない。実時間録音してるのだからどこかで補正(音トビ)しないとおかしいのは当然ではあるが……
何も考えず、サンプルレートを変えたり、設定を変えたり ASIO にしてみたり、いろいろ試行錯誤してみたがこの現象は消えなかった。最終的にクロック誤差ではないかと思いはじめた。
クロック誤差が通常の水晶を想定して±50ppm なら、48kHz のサンプルレートとしても、実際は±2.4Hz (48e3 * 50e-6) となり、最悪 (48002.4Hz vs 47997.6Hz) で考えると1秒あたり4.8サンプルずつずれていくことになる。
1分で18サンプルなら、逆算するとデバイス間に0.3Hz (18/60) 差があることになる。(0.3 / 48e3 * 1e6=6.25ppm) これは水晶の精度から考えると少ない誤差といえる。
クロックソースはホストPCとオーディオデバイスどちらもあり、完全に同期していない。リアルタイム処理だと、原理的にサンプルパーフェクトで処理することはできない。実時間に対してずれていってしまう (PCやデバイスのクロックの1秒と実時間の真の1秒の誤差) から仕方ない。
デバイスクロックがPCクロックより早い場合、PCからすれば余計にデータが送られてくるので、少しずつデータが伸びていく (その音声はPCから見れば遅れていく)。伸びていくといっても実装によって限界が生じる(バッファオーバーラン)のでそのうち音飛びする。
逆にデバイスがPCよりクロックが遅い場合、PCからすればデータが足りない(バッファアンダーラン)ので一定時間ごとに音飛びする。
複数のオーディオデバイスがある場合、この現象がそれぞれのデバイスに対して生じる。
https://www.edn.com/fundamentals-of-usb-audio/
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/audio/usb-2-0-audio-drivers
USB Audio 的にはクロックソースの選択や、クロックの同期について部分的に書かれてはいるが、ずれた結果どうすべきかは書いてない。そもそもリアルタイムの非同期転送だと送りっぱなしで再送とかもないので実は伝送エラーが起きてもそのままである (訂正されたりしない)。
アンダーランやオーバーランをどうすべきかはアプリケーションの用途によるだろうからそういうもんかとは思う (配信ソフトなら音ズレが少ないほうが好ましいが、録音ソフトなら音トビが少ないほうが好ましい、というような)
OBS は設定の「音声」にあるサンプリングレート (48k または 44.1k) が内部ではプライマリーとなっている。オーディオソースのサンプリングレートがこれと違う場合は常にリサンプリングされて統一される。ビット深度はOBS内部では常に float (=float 32bit) で処理されている。
(出力ビット深度は出力の話なのでエンコーダ設定にある)
OBS自体はオーディオ信号がきた時刻(PC内のカウンタ)を基準にサンプルを整列させていく実装になっているように見える。リサンプリングして余計なサンプルがでてきた場合、あとから生成されたサンプルで上書きされている。
つまりOBS的には、基準クロックがPC内のカウンタということになる。PCのクロックはそれほど高精度ではないという問題がある。(PC内は温度変化が激しい。TCXO積むような意味は普通ない)
この設定は Windows のみ。
結論からいえばデバイスドライバの実装が壊れていない限りオフにする必要はない。
UseDeviceTiming https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/plugins/win-wasapi/win-wasapi.cpp#L1142-L1148 というフラグ
UseDeviceTiming なら
https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer でとれる pu64QPCPosition (これはWASAPI )
パフォーマンスカウンタ (OS内の高精度でプロセッサ共通のカウンタ) から求められるタイムスタンプを算出して使う
UseDeviceTiming なら、この処理時点の os_gettime_ns を使う。os_gettime_ns は実際のところ https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/libobs/util/platform-windows.c#L481 QueryPerformanceCounter を使っている。
https://github.com/obsproject/obs-studio/blob/4953c5d517c899517a49360463ad7b70c91dea14/plugins/win-wasapi/win-wasapi.cpp#L1206-L1258 ProcessCaptureData
asio plugin は、ASIO にパフォーマンスカウンタをどうこうする仕組みはないので、コールバック時点の os_gettime_ns を使う。https://github.com/Andersama/obs-asio/blob/asio-juce/src/asio-input.cpp#L317
https://docs.obsproject.com/backend-design#general-audio-pipeline-overview
https://github.com/obsproject/obs-studio/blob/2c58185af3c85f4e594a4c067c9dfe5fa4b5b0a9/libobs/obs-source.c#L1203 MAX_TS_VAR = 2000000000ns = 2秒
ts の処理、sync_offset の追加
OBSの実装上、リサンプリングが入るので、サンプリングレートがオーディオソースごとに異なるからといって音がずれていくということはない。言いかえるとサンプリングレートが原因で音ずれるというのはOBS内では起こらない。
動画と音の場合、バッファサイズの違いが問題になる。動画はフレームを飛ばしたり重複させて時間調整しても気付きにくい。音声は動画(60Hz)に対して(48kHz)とケタ違いの分解能を持っており、数サンプル飛んでだけでもプチという高周波音で気付いてしまう。
連続して録音していく場合、オーディオインターフェイス側のクロックがホストより早いとサンプルが余り、徐々に遅れていく。余ったサンプルがどうなるかはインターフェイス側のバッファの実装による。
オーディオインターフェイス側のクロックがホストより遅いと、サンプル数がPCの想定より足りないので、定期的に音が途切れて同期する。バッファを超えて長い時間で「ずれ」はしない。
究極的にずれないようにするためには音声クロック(マスタークロック)に同期した動画のフレーム調整が必要になる。
ハードウェアクロックが複数ある場合補正して精度を高めると書いてある。どの程度の精度があるかはわからない。
https://learn.microsoft.com/ja-jp/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#absolute-clocks-and-difference-clocks
増設した直後は起動し (未フォーマットの状態)、Windows が起動後「ディスクの管理」でドライブを初期化し、シンプルボリュームを追加した。
そのあと再起動したら起動しなくなった。具体的には起動時に「オプションの選択」画面となり「続行」が表示されない状態。起動させることができないので「トラブルシューティング」するしかない。
「トラブルシューティング」からいろいろやったがダメ
ディスクが生きているし、回復画面は出るので、Windows Boot Manager までは起動して、Windows Boot Loader が起動できないということのようだ。結局、こうなると修復コンソールのコマンドラインから以下を行うとなおる。
まず修復対象のシステムパーティション(EFIボリューム)を見つける。
> diskpart DISKPART> list volume # 同じディスクのボリュームが近くに表示されるみたいなことはないので # 勘で見つけるしかない DISKPART> select volume 6 ボリューム 6 が選択されました。 DISKPART> assign letter B DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。 DISKPART> exit > B: > cd \EFI\Microsoft\Boot # バックアップを一応とっておく > copy BCD BDC.bak > bcdboot f:\windows /l ja-jp /s b:
bcdboot これは「ソース」を「f:\windows」として、ロケールを ja-jp とし、システムパーティション(ESP)として b: を指定している。
これでBCDというブートに必要なファイルが作りなおされる。
一度 diskpart を起動すると、それだけでドライブレターが割り当てられるみたい。割り当てられたら普通に cd や dir で見れる。もしかして間違えてフォーマットしていないか? ということの確認はできる。
結構調べたがよくわからなかった。前述した F: というドライブレターは回復コンソール上のコマンドプロンプトの話なので、Windows起動前であり、ここで違っていても、そこまでおかしくない。Windows起動後はレジストリエントリからドライブレターを解決するが、この段階だとまだレジストリは読まれていないはずだからだ。
BCD (Boot Configuration Data) は Windows Boot Manager で使われる設定ファイルであり、実体としては小さいレジストリファイル形式のデータベースである。
起動状態の Windows の BCD は bcdedit コマンドで見ることができる (管理者権限が必要)。ただし raw な情報を出力する方法はなく、「親切な」情報しか表示されない。なのでトラブルシューティングにはとても使いにくい。
BCD を bcdedit で見ると、device というパラメータには partition=c: とか書かれている。が、実際は partition=c: という内容が BCD に記録されているわけではない…… 現在実行中の環境のドライブレターなどを参照してそれっぽく表示している。レターの割当をなくしたりすると partition=\Device\HarddiskVolume1 みたいな形式になったりする。
BCD は Windows Registory 形式 (バイナリ) なので、Linux 向けのツールとかで、なんやかんやして読める状態のテキストファイルである .reg 形式になおすと、以下のようになっている。
11000001 というのが device にあたるエントリ。内容は、たぶんディスクの GUID やパーティションのGUIDが書かれている。
[\Objects\{6f0fb257-f0af-11ee-a710-b12de9d2818d}\Elements\11000001]
"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
00,00,00,48,00,00,00,00,00,00,00,67,5e,ec,72,84,4c,7f,4d,a5,74,08,9e,22,5c,\
38,fc,00,00,00,00,00,00,00,00,6e,22,e2,de,e4,ec,50,40,bb,b7,79,4a,a3,72,c7,\
8d,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 そうなんだよな~ 結局なんでなのかはわからなかった。BCD の差分とか眺めてみたけどわからない。
起動しなくなるのは割とショックがでかいので勘弁してほしい。
Windows は EFI が入っているパーティションのことを ESP: EFI System Pertition と呼んでいるようだ。diskpart で list volume したときに「システム」と書かれているボリュームが起動中のシステムの ESP になる。通常、ESP は FAT32 フォーマットになっており、トップレベルに EFI というディレクトリがある。通常は自動的にドライブレターがつくことはなく、非表示のボリュームとなっている。
先日、Windows が起動しなくなったときになんやかんやしていたら、以下にように D: ドライブがシステムパーティションになってしまった。NTFS でも ESP になれるんか、という発見もありつつ、気持ちが悪いので是正したいと思った。別にそのままでも問題はないが……
以下の手順でやるのが比較的安全だと思われる。
bcdboot についての公式ドキュメント: https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/bcdboot
まず、本来の EFI パーティションをマウントしなければならない。diskpart でドライブレターを割当る。
> diskpart DISKPART> list volume # 同じディスクのボリュームが近くに表示されるみたいなことはないので # 勘で見つけるしかない DISKPART> select volume 6 ボリューム 6 が選択されました。 DISKPART> assign letter B DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。 DISKPART> exit > B:
そして、割当たドライブレターを /s オプションの引数として渡して bcdboot を実行する。以下のようにする
bcdboot c:\windows /l ja-jp /s b:
これで b: に割当てたパーティションはESPとして現在のシステムを起動するようになったはず。
マザーボードの設定に入り、起動ディスクを変更する。新たに ESP を作っているので、少なくとも2つの Windows Boot Manager と名前がついたものを起動対象として選べるはず。なので、新しく作ったほうの Windows Boot Manager を選ぶ。
そして起動させてみる。
一応、ブートの挙動を書いておくと
diskpart で list volume して、意図したボリュームが「システム」になっているか確認する。
この状態で古いほうの ESP は不要になったので、とりあえずリネームとかして置いておけば良い。