--- 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.