Opened 4 years ago

Last modified 4 years ago

#1848 new defect

AMR-NB Q bit ignored

Reported by: krisha Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: amrnb
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
The Q bit determing if a frame is good or bad (errornous bits) is not used.

See bad_frame_indicator in

Attachments (1)

silence Q bit cleared.amr (8.2 KB) - added by krisha 4 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 4 years ago by cehoyos

  • Keywords amrnb added

To make this a valid ticket, please add your command line together with complete, uncut console output and add a sample.

comment:2 Changed 4 years ago by krisha

I can not give you a command line or console output for that. This I saw inside the code. And since this variable is not READ anywhere I know that it is not used. There is also no output logging for this variable.

Steps to reproduce in case someone wnats to solve it:

  1. Create a AMRNB file with 12.2 kbps and some seconds of silence
  2. Each frame starts with 0x3C and 32 bytes of data, starting directly after header
  3. Modify one 0x3C to 0x38 (Q bit cleared) and add change some random bits inside the 32 bytes of data.
  4. watch the waveform or listen to it

Actually it does not matter if the header is 0x3C or 0x38. The frame will be played or displayed anyway with the corrupt data. If I understood the RFC right, it should not be played back but just used to improve overall quality.

If someone wants to fix it, I'm here to explain in detail or to provide samples.

Version 0, edited 4 years ago by krisha (next)

comment:3 Changed 4 years ago by cehoyos

Please provide a sample.

Changed 4 years ago by krisha

comment:4 Changed 4 years ago by krisha

I attached a sample with 6 bad frames marked as BAD_SPEECH (Q cleared) at ~ 1s 660ms. I hear a small noise. But now I'm not totally sure, if in this implementation the Q bit is needed. Maybe the implementation automatically decreases the volume of bad frames even without using the Q bit. If so, a comment in the code would have been nice :)

I will continue to play with that and let you know about my results.

Please ignore the NO_DATA (0x7C) after the bad frames in the sample.

comment:5 Changed 4 years ago by cehoyos

Could you attach a wav file that contains the expected output when decoding the amr sample you provided?

Note: See TracTickets for help on using tickets.