Submit CCSMB-13: Stereo DFPWM Audio Protocol

[drucifer-sc]

Submitting CCSMB-13: Stereo DFWPM Audio Protocol

[MCJack123]

There's a lot of overlap here with the existing (and yet to be approved) CCSMB-5. And I don't see much benefit that this brings over that proposal.

• CCSMB-5 has basically the same capabilities as this proposal - it has a station field, a metadata field, and support for multiple channels of audio, all over normal modems. However, it also supports 1-8 channels with variable-length chunks instead of just two fixed chunks, and is already decoded (more about that below).
• I don't understand the benefit of using packed string data over tables. This may very slightly reduce server impact, but in exchange, it makes the format difficult to extend without breaking existing interpreters. It also introduces artificial limits that wouldn't need to exist if it was just a table.
• CCSMB-5 has much richer metadata, which is suitable for programs to display as they wish; whereas this proposal only provisions for a station name + a single title field. CCSMB-5 being a table also makes this easier to implement - stations can skip fields that they don't need to send (IIRC).
• Broadcasting DFPWM instead of decoded PCM will put extra processing impact on the MC server. Instead of decoding the data a single time on the server computer, each client must decode the data individually, which will really add up with lots of clients!

[drucifer-sc]

There's a lot of overlap here with the existing (and yet to be approved) CCSMB-5. And I don't see much benefit that this brings over that proposal. --Cool, got it, will close and destroy this.

CCSMB-5 has basically the same capabilities as this proposal - it has a station field, a metadata field, and support for multiple channels of audio, all over normal modems. However, it also supports 1-8 channels with variable-length chunks instead of just two fixed chunks, and is already decoded (more about that below). That's great but a table does not transmit well over other transport mediums. Mine was meant to be transit agnostic and survive being pushed over HTTP, WS, or modem. I don't understand the benefit of using packed string data over tables. This may very slightly reduce server impact, but in exchange, it makes the format difficult to extend without breaking existing interpreters. It also introduces artificial limits that wouldn't need to exist if it was just a table. A packed string takes up LESS bytes than a table being passed in plain text. Simple. CCSMB-5 has much richer metadata, which is suitable for programs to display as they wish; whereas this proposal only provisions for a station name + a single title field. CCSMB-5 being a table also makes this easier to implement - stations can skip fields that they don't need to send (IIRC). The station title field is intended to be broadcast at all times to ensure the station is identifiable, the title field is entirely flexible in the 255 character limit as to what you want to put there. Additionally, I was thinking of making it skippable (0 byte string). Broadcasting DFPWM instead of decoded PCM will put extra processing impact on the MC server. Instead of decoding the data a single time on the server computer, each client must decode the data individually, which will really add up with lots of clients! Packed DFPWM was selected to reduce the transmit size of the modem packets and make things a little faster. Again, it was selected to reduce the overall packet size with the intention that this format would end up being transit agnostic.

[dimaguy]

I don't see the need to destroy this given you've shown valid points and ccsmb-5 isnt even approved yet. Show some spine sir and let this battle continue until the heat death of the universe with the merit of your designed format