Bit-reservoir issues - Revision history

StefanG: /* Streaming files */

2013-04-12T11:46:59Z

Streaming files

← Older revision		Revision as of 11:46, 12 April 2013
Line 16:		Line 16:

	lame --nores original_file.mp3 new_file_without_bit_reservoir.mp3		lame --nores original_file.mp3 new_file_without_bit_reservoir.mp3


			Back to [['''[[FAQ#Audio_FAQ]]''']]

StefanG: /* Bit-reservoir in streaming */

2012-01-18T10:12:45Z

Bit-reservoir in streaming

← Older revision		Revision as of 10:12, 18 January 2012
Line 9:		Line 9:
	In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.		In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.

	On [[Instreamer 100 \| Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.		On [[Instreamer 100 \| Instreamer]] the bit-reservoir is configurable. Disable ("kept empty") it when streaming RTP.

	== Streaming files ==		== Streaming files ==

Brain: /* Bit-reservoir in streaming */

2011-05-03T12:28:36Z

Bit-reservoir in streaming

← Older revision		Revision as of 12:28, 3 May 2011
Line 9:		Line 9:
	In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.		In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.

	On [[Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.		On [[Instreamer 100 \| Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.

	== Streaming files ==		== Streaming files ==

Brain: New page: == What is bit-reservoir == One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. ...

2011-05-03T12:27:19Z

New page: == What is bit-reservoir == One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. ...

New page

== What is bit-reservoir ==

One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. If an MP3 file or stream is encoded with bit-reservoir feature enabled then the consecutive frames depend on each other. Otherwise they are completely self-contained.

The bit-reservoir feature slightly reduces the overall size of the file.

== Bit-reservoir in streaming ==

In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.

On [[Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.

== Streaming files ==

PC files are usually encoded with bit-reservoir enabled. Therefore if you decide to stream files, make sure that you create the files for streaming without bit-reservoir. You can also re-encode your existing files using e.g. Lame:

lame --nores original_file.mp3 new_file_without_bit_reservoir.mp3