ปรับระดับเสียงของหูฟังเอียร์บัดบลูทูธของฉัน
(blog.ornx.net)- เสียงระบบสำหรับการจับคู่·เชื่อมต่อ·ยกเลิกการเชื่อมต่อของเอียร์บัด Tozo T6 ดังเกินไป จึงแก้ปัญหาด้วยการลดเกนของไฟล์เสียงในเฟิร์มแวร์โดยตรง
- คาดว่าชิปเซ็ตเป็น Airoha AB1562 ตระกูลเดียวกัน และยืนยันความเป็นไปได้ในการดูข้อมูลวินิจฉัยและอัปโหลดเฟิร์มแวร์ที่แก้ไขแล้วผ่านแอป AirReps156X
- ดักทราฟฟิกการตรวจสอบอัปเดตของแอป Tozo ด้วย mitmproxy และได้ลิงก์ไบนารีเฟิร์มแวร์ของเอียร์บัดจากการตอบกลับของ
/api/v1/getOtaVersionV3 - เฟิร์มแวร์ประกอบด้วย FotaPackage 2 ไฟล์และ FileSystemImage 2 ไฟล์สำหรับหูฟังซ้ายขวา และในอิมเมจระบบไฟล์ที่เป็นเป้าหมายแก้ไขมี ไฟล์ mp3 ต้นฉบับอยู่ครบ
- ใช้
mp3gainลดระดับเสียงลงเพียง -19.5dB โดยไม่รีเอนโค้ด mp3 หรือเปลี่ยนความยาวไฟล์ จากนั้นแทนที่ไบต์ภายในอิมเมจแล้วแฟลชกลับ อุปกรณ์ยังทำงานปกติและเสียงเบาลงมาก
เสียงระบบที่ดังเกินไปและสมมติฐานตั้งต้น
- เอียร์บัด Tozo T6 จะเล่นเสียงทุกครั้งที่จับคู่ เชื่อมต่อ และยกเลิกการเชื่อมต่อ ซึ่งเสียงนี้ดังเกินกว่าระดับที่ผู้ใช้ต้องการ
- การลดทุกย่านความถี่ลงไม่กี่ dB ในอีควอไลเซอร์ไม่ช่วย และเมื่อส่งอีเมลถาม Tozo บริษัทก็ตอบว่าไม่มีอะไรที่ทำได้
- เป้าหมายคือแก้ไข เฟิร์มแวร์ ที่รันอยู่บนอุปกรณ์เพื่อลดระดับเสียงของไฟล์เสียงนั้น
- ตอนแรกเริ่มจากการตั้งข้อสมมติหลายอย่าง
- น่าจะหาไบนารีเฟิร์มแวร์ของอุปกรณ์ได้จากออนไลน์
- เฟิร์มแวร์อาจมีโครงสร้างไบนารีที่เข้าใจง่ายแบบ ELF
- ไฟล์เสียงน่าจะรวมอยู่ในเฟิร์มแวร์ และหากรู้ offset กับความยาวก็น่าจะแก้ไขได้
- เสียงอาจอยู่ในฟอร์แมตง่าย ๆ อย่าง PCM
- น่าจะมีเครื่องมือสำหรับแฟลชเฟิร์มแวร์ที่แก้ไขแล้วลงอุปกรณ์หรือชิปเซ็ตได้
- แต่ในความเป็นจริงหลายสมมติฐานผิดพลาด และเวลาส่วนใหญ่ไม่ได้หมดไปกับการทำรีเวิร์สเอนจิเนียริงโดยตรงเท่าไรนัก แต่หมดไปกับการตั้งค่า โครงสร้างพื้นฐานสำหรับการวิเคราะห์ เช่นพร็อกซี และการหาเส้นทางอ้อมแทน
ระบุอุปกรณ์และชิปเซ็ต
- อุปกรณ์อิเล็กทรอนิกราคาถูกมักเกี่ยวข้องกับหลายฝ่ายและหลายชั้น
- ผู้ขาย ที่ทำตลาดภายใต้แบรนด์ ในกรณีนี้คือ Tozo
- ชิปเซ็ตซึ่งเป็นฮาร์ดแวร์หลักที่รันเฟิร์มแวร์
- ชิปเซ็ตอาจใช้ ISA ที่ต่อยอดจากเทคโนโลยีพื้นฐานอย่าง ARM หรือ MIPS
- อาจรวมโคโปรเซสเซอร์เพิ่มเติมหรือฟังก์ชันสำหรับฮาร์ดแวร์อินเทอร์เฟซไว้ด้วย
- ระหว่างการดิแอสเซมเบิลแอป Tozo บน Android พบ Airoha SDK การอ้างอิงถึงรุ่นชิปเฉพาะ และฟังก์ชันพื้นฐานที่ใช้สื่อสารกับอุปกรณ์
- ได้ข้อมูลทิศทางจากชุมชน Reddit เกี่ยวกับของเลียนแบบ AirPods ที่
/r/airrepsและพบแอป AirReps156X ด้วย - แอป AirReps156X ใช้ Airoha SDK และสามารถแสดงข้อมูลวินิจฉัยของอุปกรณ์ Airoha ได้
- เมื่อลองเชื่อมต่ออุปกรณ์กับแอปนั้น ปรากฏสตริงวินิจฉัย
QW_1562U_SDK1.5.1จึงสรุปได้ว่าอุปกรณ์น่าจะใช้ชิปเซ็ต Airoha AB1562 ซีรีส์ - แอป AirReps156X ยังมีฟังก์ชันแฟลชเฟิร์มแวร์ใหม่ด้วย ทำให้เงื่อนไขสำคัญในการอัปโหลดเฟิร์มแวร์ที่แก้ไขแล้วลงอุปกรณ์ครบถ้วน
หา URL เฟิร์มแวร์จากทราฟฟิกของแอป Tozo
- แอป Tozo จะแสดงเวอร์ชันเฟิร์มแวร์ปัจจุบันและสถานะว่าเป็นเวอร์ชันล่าสุดหรือไม่เมื่อเชื่อมต่อกับเอียร์บัด
- จึงตั้งสมมติฐานว่าแอปต้องคุยกับเซิร์ฟเวอร์เพื่อเช็กข้อมูลเฟิร์มแวร์ล่าสุด และตัดสินใจหา URL ของไฟล์เฟิร์มแวร์จริงระหว่างขั้นตอนตรวจสอบอัปเดต
- แทนที่จะอ่านโค้ดที่ดิแคมไพล์มาแบบสแตติกจนสุด เลือกใช้ การวิเคราะห์แบบไดนามิก โดยดูคำขอเครือข่ายโดยตรง
- ตั้งค่าพร็อกซีดักจับด้วย NIC ไร้สาย,
hostapdและmitmproxy - แพตช์ Tozo APK ด้วย
apktoolและuber apk signerเพื่อให้เชื่อถือใบรับรอง TLS ของ mitmproxy จาก user CA store- แอป Android มักดูเฉพาะ system CA store โดยปริยาย
- จึงต้องแพตช์ APK ให้ใช้ user CA store ด้วย แล้วเซ็นใหม่เพื่อให้รันบน Android ได้
- การตั้งค่าพร็อกซีรวมถึงการตั้งค่า AP, การรีไดเร็กต์ทราฟฟิกพอร์ต 80/443 ไปยังพอร์ตของ mitmproxy ด้วย
iptablesและการตั้งค่า NAT - ตอนที่แอปแสดงคำว่า “current” ข้างเวอร์ชันเฟิร์มแวร์ มันได้ส่งคำขอไปยังเอนด์พอยต์
/api/v1/getOtaVersionV3และในการตอบกลับมี ลิงก์ไฟล์ bin ของเฟิร์มแวร์ ที่ต้องการอยู่
โครงสร้างไฟล์เฟิร์มแวร์และการวิเคราะห์
- เฟิร์มแวร์ที่ได้มาประกอบด้วยไฟล์ทั้งหมด 4 ไฟล์
FotaPackageสำหรับเอียร์บัดซ้ายและขวาอย่างละไฟล์FileSystemImageสำหรับเอียร์บัดซ้ายและขวาอย่างละไฟล์
- อิมเมจระบบไฟล์ทั้งสองเหมือนกัน จึงเหลือไฟล์ที่ไม่ซ้ำจริง ๆ 3 ไฟล์ คือ FotaPackage ซ้ายขวา 2 ไฟล์ และอิมเมจระบบไฟล์ 1 ไฟล์
- ใช้
file,strings,hexdump,binwalkเพื่อตรวจสอบฟอร์แมตและไฟล์ที่ฝังอยู่ภายใน - ในอิมเมจระบบไฟล์มองเห็นสตริงชื่อไฟล์บางส่วน แต่
binwalkไม่สามารถหาไฟล์ mp3 ที่คาดหวังได้ - mp3 ไม่มี magic number หรือ footer ที่ชัดเจน จึงยากที่จะระบุ offset และความยาวจากไบนารีตามอำเภอใจได้แน่ชัด
- จุดเริ่มต้นอาจเป็น
0xFFFFหรือ0xFFFE - แต่ทั้งคู่ก็ไม่เฉพาะเจาะจงพอจะใช้เป็นตัวระบุไฟล์
- จุดเริ่มต้นอาจเป็น
- จึงเปลี่ยนแนวทางไปพยายามทำความเข้าใจฟอร์แมตของอิมเมจแทน โดยคาดว่าหากรู้โครงสร้างของระบบไฟล์ก็จะรู้จุดเริ่มและจุดสิ้นสุดของแต่ละไฟล์ได้
การวิเคราะห์เอนโทรปีและ ROFS
- การวิเคราะห์เอนโทรปีมีประโยชน์ในการทำให้เห็นภาพว่าส่วนไหนของไฟล์มีลักษณะเป็นค่าคงที่ เป็นสัญญาณรบกวนแบบสุ่ม หรือใกล้เคียงข้อความ ASCII และจุดเปลี่ยนผ่านอยู่ตรงไหน
- อิมเมจระบบไฟล์ดูมีโครงสร้างที่พอมองออก แต่ไฟล์ FotaPackage ดูเหมือนถูกบีบอัดหรือเข้ารหัสไว้
- FotaPackage ของซ้ายและขวาต่างกันเพียงบางส่วนของ header ส่วนเนื้อหาเกือบเหมือนกันทั้งหมด ก่อนจะต่างกันอย่างสิ้นเชิงในช่วงท้ายประมาณ 7KB
- แม้จะยังยืนยันไม่ได้ว่าความต่างนี้หมายถึงอะไรแน่ แต่ก็ดูเหมือนมีการแปลงที่ไม่โปร่งใสอยู่ จึงประเมินว่าไม่น่าจะได้ข้อมูลที่มีความหมายโดยไม่ต้องลงแรงมาก
- อิมเมจระบบไฟล์ขึ้นต้นด้วยสตริง ASCII
ROFS - หาเอกสารสาธารณะหรือข้อมูลฟอร์แมตที่ตรงกับ
ROFSไม่เจอ แต่ภายหลังพบว่า Airoha SDK มี implementation ของอินเทอร์เฟซสำหรับอ่านอิมเมจนี้อยู่ - ช่วงหนึ่งเคยลองไล่เส้นทางถอดความหมาย FotaPackage แต่ทำได้เพียงยืนยันว่า SDK ไม่ได้แปลงเฟิร์มแวร์ก่อนส่งไปยังอุปกรณ์ และไม่ได้ผลลัพธ์เพิ่มเติม
ลดระดับเสียง mp3 โดยไม่รีเอนโค้ด
- การที่ไฟล์เป็น mp3 ตอนแรกถูกมองว่าเป็นปัจจัยเสี่ยง
- ตัวเข้ารหัส mp3 มีตัวเลือกมากมาย และตัวถอดรหัสที่ไม่รู้ที่มาอาจประมวลผลไฟล์ที่ถูกต้องตามมาตรฐานบางไฟล์ไม่ได้
- หากเสียงที่เล่นทันทีหลังเชื่อมต่อทำให้เกิดปัญหา อุปกรณ์อาจแครชก่อนจะเชื่อมต่อใหม่ได้ ทำให้กู้คืนไม่ได้
- หากรีเอนโค้ด mp3 ความยาวไฟล์อาจเปลี่ยน และอาจต้องแก้ข้อมูลความยาวในอิมเมจระบบไฟล์ให้ถูกต้องตามไปด้วย
- โชคดีที่ mp3 สามารถปรับ เกน ได้โดยไม่ต้องรีเอนโค้ด ไม่ต้องเปลี่ยนความยาว และไม่ต้องแก้เมตาดาตา
- มันคล้ายกับการหมุน JPEG โดยไม่ต้องรีเอนโค้ด คือเป็นการแก้เฉพาะบางส่วนของโครงสร้างข้อมูลภายใน
เบาะแสชี้ขาดจาก SDK
- เมื่อค้นหาด้วยชื่อชิปเซ็ต พบสำเนา Airoha SDK และข้างในมีไฟล์
.mp3แบบเดียวกับที่ได้ยินจากอุปกรณ์ - เขียนโปรแกรม Python ง่าย ๆ ชื่อ
bincontains.pyเพื่อตรวจสอบว่าไฟล์ใดถูกฝังอยู่ในไบนารีอื่นแบบเดิมทั้งก้อนไหม - ยืนยันได้ว่าไฟล์ mp3 จาก SDK อยู่ในอิมเมจระบบไฟล์ แบบต้นฉบับตามเดิม
- ไม่ได้ถูกบีบอัด
- ไม่ได้ถูกแยกเป็นบล็อก
- ดังนั้นจึงคำนวณ offset และความยาวของไฟล์ภายในอิมเมจได้
- ลองดูโค้ดใน SDK ที่เกี่ยวกับ ROFS แบบคร่าว ๆ และไม่พบสัญลักษณ์ที่บ่งชี้แรง ๆ ว่ามีเช็กซัม
- ถึงจุดนี้ เงื่อนไขที่ต้องใช้ในการแก้ไขก็ครบแล้วโดยไม่ต้องรีเวิร์สเอนจิเนียริงเพิ่ม
- มีไฟล์เฟิร์มแวร์และวิธีแฟลช
- รู้ตำแหน่งและความยาวของไฟล์ mp3 ภายในอิมเมจ
- ปรับเกนของ mp3 ได้โดยไม่เปลี่ยนความยาว
- และตั้งสมมติฐานได้ว่าการเปลี่ยนแค่ช่วงไบต์ภายในไฟล์จะไม่ทำให้เมตาดาตาของระบบไฟล์เสียหาย
แก้ไขอิมเมจระบบไฟล์และแฟลช
- สคริปต์ Bash จะไล่ดูไฟล์ mp3 จาก SDK และค้นหาไฟล์ที่ถูกฝังอยู่ภายในอิมเมจระบบไฟล์
- จากนั้นคัดลอก mp3 ที่พบออกมาเป็นไฟล์ชั่วคราว แล้วใช้
mp3gainลดเกนลง - ค่าที่ใช้ปรับคือ -19.5dB
- หลังจากยืนยันว่า mp3 ที่แก้ไขแล้วมีขนาดเท่ากับต้นฉบับ ก็ใช้
ddเขียนทับไบต์ลงที่ offset เดิมในอิมเมจระบบไฟล์ - อิมเมจเฟิร์มแวร์สุดท้ายเมื่อดู diff แบบไบนารีก็เปลี่ยนไปเพียงไม่กี่ไบต์ตามคาด
- จากนั้นแฟลชเฟิร์มแวร์ที่แก้ไขแล้วกลับลงอุปกรณ์ และอุปกรณ์ยังทำงานปกติ โดยเสียงระบบเบาลงกว่าก่อนเริ่มอย่างมาก
ผลลัพธ์และข้อจำกัด
- ไม่จำเป็นต้องถอดการเข้ารหัสของเฟิร์มแวร์หรือทำความเข้าใจฟอร์แมตระบบไฟล์
ROFSทั้งหมด - ในทางปฏิบัติ เวลาจำนวนมากของงานรีเวิร์สเอนจิเนียริงถูกใช้ไปกับเส้นทางอ้อมที่ไม่จำเป็นต่อวิธีแก้สุดท้ายโดยตรง
- หากการปรับระดับเสียงของระบบเป็นฟังก์ชันพื้นฐานของอุปกรณ์ตั้งแต่แรก ก็ไม่จำเป็นต้องแก้ไขแบบนี้
- สำหรับอุปกรณ์ที่เล่นเสียงได้ ควรมี ตัวควบคุมระดับเสียง ใน UI ที่ใช้ได้กับทุกเสียงที่ออกมาจากอุปกรณ์
- แต่ในกรณีนี้ การลดเกนของ mp3 ภายในอิมเมจเฟิร์มแวร์ก็เพียงพอที่จะเป็นวิธีอ้อมที่ใช้งานได้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
อยากให้มีคนแก้ หน้ากากนอนบลูทูธ ของฉันแบบนี้บ้าง
โดยรวมก็ค่อนข้างดี แต่พอแบตใกล้หมดหรือถึงเวลาจะปิด มันจะแจ้งเรื่องนั้นด้วย เสียงดังสุด
จากหน้ากากนอนนี่แหละ
ผมเคยใช้นาฬิกาปลุกที่มีข้อบกพร่องคล้าย ๆ กัน มันมีฟีเจอร์ ซิงก์เวลาผ่านสัญญาณวิทยุ MSF
แต่ทุกครั้งที่มันซิงก์กับสัญญาณเวลา MSF ใหม่ มันจะส่งเสียงแบบเดียวกับเสียงปลุกอยู่ 2–3 วินาที และปิดไม่ได้ด้วย
มักจะดังตอนเวลานรก ๆ อย่างตี 3 เสมอ สุดท้ายเลยแกะออกมาดูแล้วตัดเสาอากาศ MSF ทิ้ง แล้วก็นอนหลับดีขึ้นทั้งที่รู้ว่านาฬิกาจะคลาดเคลื่อนนิดหน่อยตลอด
ระหว่างนั้นก็พยายามไล่ตามให้ทันว่าคู่สนทนาพูดอะไรไปบ้างในช่วงไม่กี่วินาทีนั้น แต่แทบไม่ทัน
การแจ้งเตือนนี้แย่กว่าการไม่ทำอะไรเลยมาก ถ้าไม่มีการเตือน สิ่งที่แย่ที่สุดก็คือเสียงขาดจนพลาดคำพูดของอีกฝ่าย แต่เจ้าคลิปหูกลับจงใจสร้างผลลัพธ์เดียวกันนั้นให้เกิดเร็วขึ้น
ไม่มีเหตุผลเลยที่มันจะผสมเข้าไปในสตรีมเสียงเดิมเป็น แพตเทิร์นเสียงบี๊บที่ไม่รบกวนสายตา อะไรทำนองนั้นไม่ได้ ใช้เวลาไม่ถึงวินาที และจะไม่สร้างปัญหาที่มันตั้งใจจะป้องกันขึ้นมาเองด้วย
พฤติกรรมบลูทูธแย่ ๆ ที่นึกภาพได้ยากอีกอย่างคือ พอใช้แชตเสียง เสียงคอมพิวเตอร์ทั่วไปทั้งหมดก็หายไป ถ้าแชตเสียงใช้ไมค์ อุปกรณ์บลูทูธจะเปลี่ยนเป็นโหมด “headset” และโหมดนี้จะเปลี่ยนสเตอริโอเป็นโมโน พร้อมกลายเป็นเอาต์พุตเดียวที่อนุญาตระหว่างที่กำลังให้ หรืออาจจะให้ อินพุตเสียง
แอปที่ไม่ได้ใช้อินพุตเสียงก็ยังพยายามเล่นไปยังอุปกรณ์หูฟังบลูทูธที่ไม่มีอยู่แล้วต่อไป ทำให้ทั้งหมดส่งเสียงไม่ได้
ไม่เข้าใจว่าทำไมอุปกรณ์ต้องมีหลายโหมดด้วย ไม่มีเหตุผลอะไรที่ผมจะอยากเสียฟังก์ชันไปเป็นผลข้างเคียงของการคุยกับครอบครัว ไม่เข้าใจว่าการเล่นสัญญาณเสียงต่างกันพร้อมกันในหูทั้งสองข้างมันยากตรงไหน เพียงเพราะไมค์อาจจะถูกเปิด อุปกรณ์ที่ไม่ใช่บลูทูธก็จัดการเรื่องนี้ได้ และถึงขั้นไม่ถูกนับว่าเป็นฟีเจอร์เด่นด้วยซ้ำ ทำไม “หูฟังไม่ดับระหว่างใช้ไมค์” ถึงต้องเป็นเรื่องพิเศษ?
เจ๋ง! ผู้เขียนต้นฉบับเก่งมากที่ทำจนจบ
พูดถึงเอียร์บัดเสียงดังแล้ว ผมอาจมีปัญหาตรงกันข้าม ผมใช้ เอียร์บัดสำหรับออกกำลังกายของ Bose บนลู่วิ่งในระดับเสียงที่คิดว่าสบายและค่อนข้างระวังแล้ว แต่ iPhone กลับแจ้งว่าเสียงดังเกินไปและกำลังทำลายการได้ยินของผม
โทรศัพท์เป็นฝ่ายถูกหรือเปล่า? ถ้าใช่ ผมก็ยอมเสียความเพลิดเพลินไปนิดหน่อยเพื่อสุขภาพหูได้ แต่ก็มีสมมติฐานอื่นที่ฟังขึ้นเหมือนกัน เอียร์บัดตัวนี้ที่ค่าระดับเสียงเดียวกัน ให้ระดับความดังทางกายภาพจริงต่ำกว่าผลิตภัณฑ์อื่น ๆ ที่ผมเคยใช้ชัดเจน ดังนั้นโมเดลแบบขี้เกียจของ Apple อาจสร้างการแจ้งเตือนผิด ๆ แบบที่ผมได้รับอยู่ก็ได้
ถ้า Apple ทำฐานข้อมูลที่แมปโมเดลสินค้าและการตั้งค่าระดับเสียงเข้ากับระดับความดังทางกายภาพจริง ผมก็อยากชื่นชม แต่ในการแจ้งเตือนและคำอธิบายฟีเจอร์ไม่มีรายละเอียดอะไรเลย ทำให้ไม่น่าเชื่อถือ และผมก็ไม่อยากทำให้การออกกำลังกายแย่ลงเพียงเพราะ Apple เอาโมเดลระดับการบ้านมหาวิทยาลัยมาใส่ในผลิตภัณฑ์จริง
มีใครรู้ไหมว่า data science ที่รองรับการแจ้งเตือนนี้มันดีจริงหรือเปล่า?
อย่างแรก บน iOS ระดับเสียงต่ำสุดของเอียร์บัดบลูทูธของผมยังดังเกินไป เป็นแบบนี้กับหูฟัง third-party ทุกตัวที่เคยใช้ และในออนไลน์ก็มีคนบ่นกันมาสิบปีแล้ว EU ถึงขั้นออกกฎหมายให้แก้ แต่สปอยล์: ไม่ได้ผล
ขอร้องเถอะ ระดับเสียงต่ำสุดใน UI ควรแมปกับค่าจำนวนเต็มระดับเสียงของฮาร์ดแวร์ที่ 1
อย่างที่สอง แอป third-party ไม่สามารถแสดงเพลงหรือพอดแคสต์ในเมนูเรียกดูสื่อผ่านบลูทูธของรถได้ บน Android ทำได้
ดังนั้นบน Android ผมใช้ปุ่มหมุนของรถฟังพอดแคสต์และสตรีม Tidal ได้ แต่บน iOS ทำไม่ได้
ยังมีเรื่องบ่นเกี่ยวกับบลูทูธอื่น ๆ อีก ทำไม Apple Watch ของผมถึงขึ้นบัญชีดำสเตอริโอรถ? บลูทูธใน iOS เวอร์ชัน N และ N-1 บั๊กเยอะจริง ๆ
มันเป็นฟีเจอร์ที่โง่อย่างเห็นได้ชัด ถ้ารูตได้ก็คงปิดสวิตช์นั้นในไฟล์คอนฟิกที่ไหนสักแห่งได้ แต่กับ Samsung Galaxy J1 (2016) ผมไม่เคยทำสำเร็จเลย
Bose ของผมก็ทำงานต่างกันขึ้นกับชิปเซ็ตบลูทูธเหมือนกัน บน Linux ถ้าจะให้ได้ยินอะไรชัด ๆ ต้องปรับระดับเสียงเป็น 150%
แต่ก็ไม่มีเหตุผลให้เชื่อว่าพวกเขาทำแบบนั้น ถ้าผู้ผลิตหูฟังรายงานช่วง dB ตอนเชื่อมต่อบลูทูธเพื่อให้ทำฟีเจอร์แบบนั้นได้ก็น่าสนใจ แต่ไม่เคยได้ยินว่ามีแบบนั้น ต่างจากแจ็ก 3.5 มม. บลูทูธเป็นพื้นที่ที่น่าจะทำให้ฟีเจอร์แบบนั้นเป็นไปได้อยู่แล้ว
ถ้าใช้การตัดเสียงรบกวน คุณจะรักษาระดับเสียงให้อยู่ต่ำกว่า 20% ได้ แต่ก็ยังฟังได้สบายโดยไม่ทรมานหู
กรณีของผม เมื่อไม่กี่ปีก่อนหลังออกกำลังกายนาน ๆ เริ่มมีอาการปวดหู เลยคิดว่าการแจ้งเตือนของ Apple น่าจะถูก หลังจากใช้การตัดเสียงรบกวน อาการก็หายไปหมดเลย
งานแบบนี้ดีมาก จู่ ๆ หูฟังรุ่นนี้ก็ดูน่าสนใจขึ้นมาพอสมควร
ว่าไปแล้ว เสียงระบบ ที่อุปกรณ์ Bluetooth ส่งออกมาเป็นหนึ่งในปัจจัยที่ทำให้สินค้าแตกต่างกันอย่างแรงที่สุด บางอันก็แย่สุด ๆ: https://youtu.be/J2wPsH64JEM
แต่ผมไม่เคยเห็นรีวิวหรือหน้าสินค้าบอกเลยว่าสินค้านั้นส่งเสียงแบบไหน ทั้งที่ต้องฟังวันละหลายครั้ง แถมยังปิดไม่ได้ด้วย
แค่ทำให้เปลี่ยนเสียงพวกนี้ได้ ก็น่าจะเป็นจุดต่างที่ทำได้ค่อนข้างง่ายแล้ว
เวลาใส่ที่อุดหูอยู่ในสถานที่ทำงานที่เสียงดังมันก็เหมาะมาก แต่พออยู่ในออฟฟิศเงียบ ๆ แล้วเปิดเพลงเบา ๆ เพื่อโฟกัส มันกลับน่ารำคาญและทำให้สะดุ้ง
ไม่เข้าใจว่าทำไมเสียงระบบถึงไม่อิงตามการตั้งค่าระดับเสียง
คงดีถ้าโทรศัพท์รู้ได้ว่าหูฟังที่เชื่อมต่ออยู่เป็น ชุดลำโพง, in-ear monitor, แบบ bone conduction ฯลฯ
เวลาใช้ชุดลำโพงทั่วไปแล้วตั้งใจเปิดดัง ๆ เพื่อให้ได้ยินทั่วบ้าน การแจ้งเตือนว่า “ระดับเสียงดังเกินไป” น่ารำคาญมาก
หูฟัง bone conduction ต้องใช้ระดับเสียงค่อนข้างดังถึงจะฟังชัด เลยยิ่งน่ารำคาญเป็นสองเท่า
โชคดีที่นี่เป็น เป้าหมาย Airoha ที่ไม่มีการเข้ารหัสเฟิร์มแวร์
ถ้าสนใจ ก็มีเทมเพลต 010 Editor สำหรับรูปแบบเฟิร์มแวร์ด้วย
https://github.com/ramikg/airoha-firmware-parser
ยอมรับในฝีมือนะ แต่ก็น่าเสียดายที่ต้องใช้ความพยายามถึงขนาดนี้เพื่อทำเรื่องพื้นฐานอย่างการปรับระดับเสียงของไฟล์ที่เล่นนิดหน่อย
ไม่ควรต้องลำบากขนาดนี้เพื่อทำให้เครื่องมือทำงานตามที่เราต้องการ
ไม่ใช่เรื่องที่ “เข้าใจได้” เราจ่ายเงินซื้อสินค้าไปแล้ว และนี่คือ ปัญหาของสินค้า ที่ควรแก้
หลังอ่านบทความนี้ ผมซื้อ Tozo T6 มือสองมา แม้ภายนอกดูเหมือนผลิตค่อนข้างไม่นานนี้ แต่ก็ทำซ้ำไม่ได้
แอป Tozo ทางการก็ไม่รู้จักหูฟัง และผมยืนยันไม่ได้ว่าใช้ชิปเซ็ต Airoha ที่ระบุได้จากการรองรับ AAC หรือไม่ ของผมรองรับแค่ SBC
ดูเหมือนว่าผมอาจซื้อของปลอมมา หรือไม่ก็มีการเปลี่ยนชิ้นส่วนภายในหลังจากผู้เขียนซื้อไปแล้ว
ไฟล์เสียงบางไฟล์ฟังเหมือนกับที่อยู่ใน Airoha SDK บางส่วนบนอินเทอร์เน็ต แต่ก็เล่นไฟล์เสียงใหม่อื่น ๆ ด้วย
ถ้าอยากตรวจสอบผลลัพธ์นี้อย่างอิสระหรือเอาไปลองเล่น AirPods ปลอม อาจเป็นทางที่ดีกว่า
อยากให้คนบ่นเรื่อง เสียงระบบที่ดังและแย่ กันมากขึ้น
Sony WH-1000XM4 ของผมก็มีปัญหาเหมือนกันเป๊ะ และดูเหมือนว่า Sony จะเข้ารหัส payload ของเฟิร์มแวร์แล้วถอดรหัสบนตัวอุปกรณ์
เกือบจะแกะออกมา dump ทั้งหมดแล้วสำรวจดูอยู่แล้ว แต่ผมมือสั่น โอกาสทำพังมีสูงเกินไป
ถ้ามีหูฟังตัดเสียงรบกวนที่แฮ็กได้ ผมยินดีจ่ายเงินก้อนใหญ่ทีเดียว