# HG changeset patch # User Mychaela Falconia # Date 1713391729 0 # Node ID 78739fda285600963891f12fceeed1e5b242fabb # Parent 83408f67a96cd74261dda818108650c9da81af02 doc/AMR-EFR-conversion: update for current understanding diff -r 83408f67a96c -r 78739fda2856 doc/AMR-EFR-conversion --- a/doc/AMR-EFR-conversion Wed Apr 17 20:53:10 2024 +0000 +++ b/doc/AMR-EFR-conversion Wed Apr 17 22:08:49 2024 +0000 @@ -1,3 +1,11 @@ +Please see our AMR-EFR-philosophy article for an analysis of differences between +EFR and MR122 (12k2 mode of AMR), and for a discussion of how we handle the +relation between these two codecs. The following article was written in late +2022, before these issues were properly understood: + +2022-December description +------------------------- + We have two simple utilities that allow one to experiment with "dumb" bit- shuffling conversion between AMR 12k2 and EFR codec formats, to explore capabilities and limitations of this approach. @@ -23,3 +31,48 @@ give them any special handling, instead they will be bit-reshuffled into MR122 just like EFR speech frames. The result of such "dumb" conversion is invalid AMR, and when you decode it with amrnb-dec, you will hear some strange noises. + +2024-April addendum +------------------- + +In addition to the SID issue noted above (if the input to gsm-efr2amr contains +any SID frames, the output will be invalid AMR), these dumb conversion methods +fail to take action on any embedded decoder homing frames. The correct DHF is +different between EFR and MR122, hence a better converter could be made to +recognize EFR DHFs in EFR->AMR direction and convert them to MR122 DHF, and do +the opposite in AMR->EFR direction. However, the implementation of AMR in +libopencore-amrnb has the homing feature stripped out altogether, hence doing +DHF conversion would be pointless as long as amrnb-enc and amrnb-dec utilities +are involved. + +Thoughts on more proper conversion +================================== + +Imagine this hypothetical scenario: you operate a GSM network, and you +preferentially use EFR codec. You are then able to obtain TrFO interconnection +with some other mobile network of more "modern" kind, and that "modern" network +uses AMR exclusively, with no ability to use any GSM-only codecs. (The latter +situation holds for UMTS and VoLTE, for example.) Ordinarily, under these +circumstances TrFO won't be possible - instead you have to interconnect in +G.711, have each side transcode its respective codec, and put up with double +transcoding. But what if the AMR side can be told to use MR122 only, without +any of the lower modes? Such arrangement would make no sense in GSM (just use +EFR instead and save the headache of dealing with AMR), but it might be sensible +to ask the UMTS/VoLTE side for that MR122-only config of AMR-NB. + +In this hypothetical scenario, would it be possible to pass speech frames +transparently, doing only the necessary bit reshuffling, and only invoke some +slick innovative algorithm during speech pauses to translate between EFR and +AMR SID paradigms? + +Right now this idea is fantasy only. I don't know enough about VoLTE to tell +whether or not an MR122-only config of AMR-NB would work there, I have no idea +what codec config VoLTE operators run with currently when the other end of the +call is G.711 PSTN, and there is very little chance that any of the nation-scale +mobile operators would agree to a private peering interconnect with some tiny +community GSM network - while interconnection through fully public, open-to- +everyone IP-PSTN routes allows only G.711 and nothing else, no cellular TrFO. + +Nonetheless, the idea of TrFO conversion between EFR and MR122-only AMR remains +interesting as a theoretical exercise, and we currently leave it there, just as +food for thought.