- このトピックには3件の返信、1人の参加者があり、最後ににより2時間、 25分前に更新されました。
-
投稿
-
Hello Tiki,
I’m a bit confused about why WAV files are being forced through the “WavProxy” process.
When I manually add audio/x-wav to the MIME types list, the issue disappears and the file is played directly without WavProxy.
After some testing, I eventually found this discussion:
From what I understand, it seems TuneBrowser performs some additional checks for certain formats.
However, according to RFC 6648, MIME types beginning with the x- prefix have been deprecated since 2012:https://datatracker.ietf.org/doc/html/rfc6648
Because of this, some DMR devices—especially commercial international brands—no longer include any x-* MIME types in their supported format list.
Their MIME tables typically only contain the standardized types such as audio/wav.This leads me to wonder:
Why does TuneBrowser require audio/x-wav to be present in order to avoid using WavProxy, even when the DMR advertises support for audio/wav?
Is TuneBrowser applying additional format validation beyond the MIME list provided by the DMR?If you could clarify this behavior, it would help me understand the reasoning behind the WavProxy fallback.
Thank you very much for your continued development of TuneBrowser.
I did not see this issue when testing with version 5.8.1.
Please don’t strictly require MIME types that begin with the “x-” prefix.
There is no such rule in IANA, and RFC 6648 officially deprecated the “x-*” convention.
The reason many DMRs still list MIME types beginning with “x-” is simply due to historical legacy, not because they follow a formal standard.
Thank you very much for your excellent work.
- このトピックに返信するにはログインが必要です。