Re: [codec] Opus comparison test plan version 2

["Christian Hoene" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] Im Auftrag von
Jean-Marc Valin
Gesendet: Mittwoch, 17. April 2013 20:03
An: Alfons Martin
Cc: Christian Hoene; [e-mail]; [e-mail]
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 
> [e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/codec