comparison doc/AMR-EFR-conversion @ 312:78739fda2856

doc/AMR-EFR-conversion: update for current understanding
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 17 Apr 2024 22:08:49 +0000
parents 8eb0e7a39409
children
comparison
equal deleted inserted replaced
311:83408f67a96c 312:78739fda2856
1 Please see our AMR-EFR-philosophy article for an analysis of differences between
2 EFR and MR122 (12k2 mode of AMR), and for a discussion of how we handle the
3 relation between these two codecs. The following article was written in late
4 2022, before these issues were properly understood:
5
6 2022-December description
7 -------------------------
8
1 We have two simple utilities that allow one to experiment with "dumb" bit- 9 We have two simple utilities that allow one to experiment with "dumb" bit-
2 shuffling conversion between AMR 12k2 and EFR codec formats, to explore 10 shuffling conversion between AMR 12k2 and EFR codec formats, to explore
3 capabilities and limitations of this approach. 11 capabilities and limitations of this approach.
4 12
5 gsm-amr2efr reads an AMR speech recording in RFC 4867 storage format (the common 13 gsm-amr2efr reads an AMR speech recording in RFC 4867 storage format (the common
21 BFI markers will be turned into AMR NO_DATA frames. The same input can also 29 BFI markers will be turned into AMR NO_DATA frames. The same input can also
22 contain EFR SID frames - however, gsm-efr2amr will not detect them and won't 30 contain EFR SID frames - however, gsm-efr2amr will not detect them and won't
23 give them any special handling, instead they will be bit-reshuffled into MR122 31 give them any special handling, instead they will be bit-reshuffled into MR122
24 just like EFR speech frames. The result of such "dumb" conversion is invalid 32 just like EFR speech frames. The result of such "dumb" conversion is invalid
25 AMR, and when you decode it with amrnb-dec, you will hear some strange noises. 33 AMR, and when you decode it with amrnb-dec, you will hear some strange noises.
34
35 2024-April addendum
36 -------------------
37
38 In addition to the SID issue noted above (if the input to gsm-efr2amr contains
39 any SID frames, the output will be invalid AMR), these dumb conversion methods
40 fail to take action on any embedded decoder homing frames. The correct DHF is
41 different between EFR and MR122, hence a better converter could be made to
42 recognize EFR DHFs in EFR->AMR direction and convert them to MR122 DHF, and do
43 the opposite in AMR->EFR direction. However, the implementation of AMR in
44 libopencore-amrnb has the homing feature stripped out altogether, hence doing
45 DHF conversion would be pointless as long as amrnb-enc and amrnb-dec utilities
46 are involved.
47
48 Thoughts on more proper conversion
49 ==================================
50
51 Imagine this hypothetical scenario: you operate a GSM network, and you
52 preferentially use EFR codec. You are then able to obtain TrFO interconnection
53 with some other mobile network of more "modern" kind, and that "modern" network
54 uses AMR exclusively, with no ability to use any GSM-only codecs. (The latter
55 situation holds for UMTS and VoLTE, for example.) Ordinarily, under these
56 circumstances TrFO won't be possible - instead you have to interconnect in
57 G.711, have each side transcode its respective codec, and put up with double
58 transcoding. But what if the AMR side can be told to use MR122 only, without
59 any of the lower modes? Such arrangement would make no sense in GSM (just use
60 EFR instead and save the headache of dealing with AMR), but it might be sensible
61 to ask the UMTS/VoLTE side for that MR122-only config of AMR-NB.
62
63 In this hypothetical scenario, would it be possible to pass speech frames
64 transparently, doing only the necessary bit reshuffling, and only invoke some
65 slick innovative algorithm during speech pauses to translate between EFR and
66 AMR SID paradigms?
67
68 Right now this idea is fantasy only. I don't know enough about VoLTE to tell
69 whether or not an MR122-only config of AMR-NB would work there, I have no idea
70 what codec config VoLTE operators run with currently when the other end of the
71 call is G.711 PSTN, and there is very little chance that any of the nation-scale
72 mobile operators would agree to a private peering interconnect with some tiny
73 community GSM network - while interconnection through fully public, open-to-
74 everyone IP-PSTN routes allows only G.711 and nothing else, no cellular TrFO.
75
76 Nonetheless, the idea of TrFO conversion between EFR and MR122-only AMR remains
77 interesting as a theoretical exercise, and we currently leave it there, just as
78 food for thought.