sampleSizeInBits决定每采样点的位宽、符号性及字节序处理方式；影响AudioInputStream和SourceDataLine的数据解析逻辑，需同步更新frameSize，否则导致数据错位或播放异常。
Java中AudioFormat的sampleSizeInBits到底影响什么
它不直接决定“数据怎么存”，而是告诉AudioInputStream和SourceDataLine：每采样点占多少位、是否带符号、是否需字节序转换。比如sampleSizeInBits=16且signed=true时，Java默认按小端、有符号short解析；而sampleSizeInBits=8则按无符号byte处理（即使你传入负值，也会被截断或补码解释）。
常见误操作是直接用ByteBuffer.get()读16位数据却忽略字节序，或把8位音频当成有符号数做归一化——结果爆音或静音。
8位转16位：必须补零扩展，不能简单左移
8位音频通常是无符号的（0–255），要转成16位有符号（−32768–32767），得先减去128中心化，再左移8位。否则直接byteValue 会把0x80变成0x8000（−32768），但原始8位0x80本意是中间电平（128），应映射为0。
- 错误写法：
short s = (short) (b << 8); // b是byte，0x7F→0x7F00（32512），但0x80→0x8000（−32768），失真
- 正确做法：
short s = (short) ((b & 0xFF) - 128); // 先转无符号int，再中心化
- 若目标是线性缩放（保持动态范围）：
short s = (short) (((b & 0xFF) - 128) << 8); // 0→−32768, 255→32512
16位转8位：务必先饱和裁剪再右移
16位样本范围是−32768–32767，直接(byte)(s >> 8)会导致溢出（如s=32767 → 0x7FFF>>8 = 0x7F = 127，合理；但s=−32768 → 0x8000>>8 = 0x80 = −128，而8位无符号期望0–255）。
立即学习“Java免费学习笔记（深入）”；
- 先转为无符号16位等效值：
int u16 = s & 0xFFFF; // −32768→0x8000→32768
- 再映射到0–255：
byte b = (byte) ((u16 >> 8) & 0xFF); // 安全右移
- 更稳妥（防溢出）：
int clipped = Math.max(0, Math.min(65535, s & 0xFFFF));<br>byte b = (byte) ((clipped >> 8) & 0xFF);
用AudioInputStream链式转换时，别跳过AudioFormat重建
Java不支持原地修改AudioFormat。每次采样大小变更，都必须构造新AudioFormat并用AudioSystem.getAudioInputStream(...)包装原流——否则read()返回的字节数仍按旧格式解包，导致数据错位。
例如从16位转8位：
AudioFormat oldFmt = audioStream.getFormat();
AudioFormat newFmt = new AudioFormat(
oldFmt.getEncoding(),
oldFmt.getSampleRate(),
8, // sampleSizeInBits
oldFmt.getChannels(),
oldFmt.getChannels(), // frameSize: 8位单声道=1字节/帧
oldFmt.getSampleRate(),
false // isBigEndian（8位无字节序概念，设false即可）
);
AudioInputStream converted = AudioSystem.getAudioInputStream(newFmt, audioStream);注意frameSize必须同步更新：16位单声道是2字节/帧，8位就是1字节/帧；设错会导致read()一次读不够或越界。
最易被忽略的是：不同采样大小对应不同的frameSize和frameRate语义，而Java音频API底层依赖这两者对齐缓冲区。哪怕数据内容算对了，格式描述错半字节，播放就会周期性卡顿或啸叫。
