Opened 11 years ago

Last modified 11 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 11 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 by Carl Eugen Hoyos, 11 years ago

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 by krisha, 11 years ago

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 31 bytes of data, starting directly after header
  3. Modify one 0x3C to 0x38 (Q bit cleared) and add change some random bits inside the 31 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.

Last edited 11 years ago by krisha (previous) (diff)

comment:3 by Carl Eugen Hoyos, 11 years ago

Please provide a sample.

by krisha, 11 years ago

Attachment: silence Q bit cleared.amr added

comment:4 by krisha, 11 years ago

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 by Carl Eugen Hoyos, 11 years ago

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.