Hello Jean-Marc, I do not get your arguments.
* the 8.85 issues have been considered. It has been replaced with 12.65 plus DTX * low-pass filtering has been removed * VBR is used in the music modes. * and, because of the many requests, we will compare AMR-WB with both Opus CBR und Opus VBR. Happy? What else? Christian -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Jean-Marc Valin Gesendet: Mittwoch, 17. April 2013 20:03 An: Alfons Martin Cc: Christian Hoene; [email protected]; [email protected] Betreff: Re: [codec] Opus comparison test plan version 2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, my original email had 13 points, most of which seem to have been ignored, including the low-pass filtering of speech and music, the 8.85 kb/s, and the VBR issue. So I guess I'm done with the reviewing. Good luck with your test. Cheers, Jean-Marc On 04/17/2013 09:50 AM, Alfons Martin wrote: > > > AMR-WB > > > > Based on the feedback we changed the document. > > 1) No input bandwidth filtering for speech at all > > 2) Make sure to tell the Opus encoder what the percentage of > loss is so it can optimize the encoding for it. Ok, but we have to > consider both cases. > > 3) For AMR-WB the 8.85 mode is "intended to be used only > temporarily during severe radio channel conditions or during network > congestion". Right, better we use AMR-WB 12.65 with DTX in this case. > > > > We did not consider the following suggestion > > 1) Opus should use VBR For direct comparison, we have to > choose same mode as the other codec. For example, AMR-WB does not > support VBR. > > 2) If you're going to test packet loss, there should be at > least one test with FEC -- probably the 23.85 one. As for now, we are > not sure whether the Opus FEC implementation is bug free (see FEC > question email). > > > > AAC-eLD > > Based on the feedback we changed the document. > > 1) We will use SBR > > 2) Mono and stereo should not be mixed in one experiment to > avoid the influence of this factor on the assessment of the coding > quality. agreed. > > 3) 24, 32, 48 kbit/s for mono at 32 kHz sample rate CHECK > > 4) For stereo 32, 48, 64 and 96 kbit/s could be used. CHECK > > > > We did not consider the following suggestion > > 1) > > > > > > > > General > > Based on the feedback we changed the document. > > 1) We will use loss rates 0, 1, 3, 6% > > > > We did not consider the following suggestion > > 1) We will keep the MNRU 16 anchor (MOS 2.2) because some of > the samples will be worse than LP 3.5 but better than MOS 2.2. We skip > LP 7 as it is optional. > > 2) We stick to MUSHRA as it is the only tests that covers a > wide range of degradations. > > > > Thank you very much for your timely feedback. > > > Alfons, Christian > > > > _______________________________________________ codec mailing list > [email protected] https://www.ietf.org/mailman/listinfo/codec > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRbuPdAAoJEJ6/8sItn9q935wIAIra0oye/5HW7LMQ4rt4vQ1d iIlzzNxYuravA/IHYVdlh7pfkrdoFRTNtp7RXCI8lOQEVUC0QeSS4mibtVnQyCgM PgOYvGXu2W3nQxBo12A5hFLZkFJ50Gpw42o7IaWA3G7JSCoSGvsCRQp56o+E9Nhe jN1TwlmLS5kEgWSZk+DDWtyie/VGn/X/Q+fp/DzQHYBbVHLtnYMZAWigsAEyoIWL 0z4SkpMBIEo7lctedf23LROslbiefq61K9neRhqQLMMo46Nu23IzVPHqdgnbthxi oaQcvXpLix25e9CyMhoOnfTIzCnwXKO3XLPq0jgA0CRX8B5WrTYXqzBWLtYlQD0= =GViO -----END PGP SIGNATURE----- _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
