Back to overview Documentation version 9.23
Controls the built-in MicroMPX encoder.
MicroMPX is a codec that can be used to send the full composite signal, including pilot and RDS, with perfect peak control and no MPEG-like artifacts, from Stereo Tool to your transmitter, using only low bitrates.
Several error recovery and redundancy measures are built in.
Quality settings panel
Settings that control the MicroMPX audio quality.
- µMPX Enabled
Note that separate target IP/Port addresses still needs to be enabled for any data to go out.
The bitrate that MicroMPX uses.
For MicroMPX 1, 320 kbit/s is normally sufficient, but if Allow L-R spectrum asymmetry if louder (may deteriorate reception) is used, a higher value (384 kbit/s) is recommended.
- Keyframe interval
Sets the time between keyframes.
If packets are lost (even after using redundant streams and Error correction), audio can only resume after reception of a keyframe.
Normal output panel
Error correction panel
Settings that control recovery of lost network packets.
MicroMPX sends approximately 96 packets per second. If a network connection drops out for a moment, this will typically lead to one or more packets in sequence to be lost.
These packets can be recovered by sending error recovery data in extra packets. Sending error recovery data slightly increases the bitrate, but greatly reduces the chance of getting audio dropouts due to network issues.
On a perfectly reliable network, it's not needed to use this.
Some people have asked for the possibility to send the same stream twice over the same connection, with a 1 second delay, as a means of redundancy. Instead of that, you can set both Error correction span (delay) and Error correction overhead to 120 packets (the number of packets that are sent in about 1.5 seconds). That way, any drop that takes less than 0.7 seconds will be fully recovered. (Note: The total of the two sliders may not exceed 255, that's why we can only go to 120).
- Error correction span (delay)
The number of packets over which the Error correction overhead packets are sent.
This is best explained using some numbers. Let's say that Span is set to 64 packets, and Error correction overhead is set to 4 packets. Then that means that for every 64 normal packets, 4 extra recovery packets will be sent. This causes 6.25% (4/64) overhead. With these settings, of the total of 68 (64 + 4) packets, any set of upto 4 packets can be recovered if they are lost.
With 32 and 2, which has the same amount of overhead, any set of 2 packets of the total 34 can be recovered if lost.
This may seem to be very similar, but packets often are dropped in burst, so typically 64/4 will recover far more lost packets than 32/2, and even 32/4 will only recover slighty more packets than 64/4, at double the overhead.
The only problem with larger Span values is that they require more delay at the decoder end. If the first of 64 packets is lost, in order to recover it, at least one recovery packet is needed to recover it. And the recovery packets are sent after sending all the normal packets in the Span. So, with 96 packets per second, around 700 ms of latency is needed to enable recovery for 64 packets. For 32 it's only half that.
- Error correction overhead
The number of recovery packets per Error correction span (delay) normal packets.
This value should normally be (a lot) lower than Error correction span (delay).
- Rate limiter
Limits how fast (recovery) packets can be send to the network.
Many networks have limitations in how many packets they can process, if large numbers of Error correction overhead packets are sent in burst, some of them (plus some real packets that come afterwards) can get dropped, actually deteriorating reception on the other end.
- Limit rate below
The maximum total bitrate of normal plus recovery packets.
Recovery packets can in some cases be a bit bigger than normal packets. So a few kbit/s overhead is recommended. If no overhead is available above the (calculated) total bitrate based on normal plus recovery packets, then any excess recovery packets are dropped.
GPS synchronization panel
Enables GPS time stamping. Requires a GPS receiver!
- GPS time stamping
Enables GPS time stamping. Requires a GPS receiver!
With GPS time stamping, you can keep transmitters in a Single Frequency Network (SFN) in sync, within about 1 microsecond (1 millionth of a second).
You have a Single Frequency Network if you have multiple transmitters that transmit at the exact same frequency with overlapping reception areas. By precisely adjusting the delay between the transmitter, taking the speed of light, where signals from both transmitters are about equal in strength and where large groups of potential listeners are into account, you can make sure that on a line between the transmitters there's good reception, and the signals do not interfere with each other.
Note: This is NOT needed for RDS AF switching!
- GPS NMEA device
Selects a GPS NMEA device.
In most cases, a driver is needed to talk to GPS receivers, which typically have an RS232-type interface, to make them work via USB. (If you have an RS232 interface on your pc, you can probably use it directly.)
When selecting a COM port, it will be opened at 9600 baud, 8 bits, Negative parity, 1 stop bit. For any other settings use Name.
Selects an NMEA input file/name.
Usually, you should select a COM port in GPS NMEA device. If the NMEA is routed in some other way, or if the standard COM port settings are incorrect, selecting the name might work.
Settings that protect the MicroMPX stream against external interference.
- Password protect stream
Encodes the stream to make it hard for external parties to take over the stream.
(We say "make it hard" because in the end, anything can be hacked).
- Active hash
Hash code used for encoding the stream.
This code must be the same on the encoder and all decoders.
In general it's a bad idea to show this code... But: You need it if you ever want to add an extra decoder to your stream. And if someone has access to this interface, they can interfere with everything already.
- New password
Enables entering a password, which is transcoded to a hash.
You can enter a password here, which is hashed and put in Active hash.
- Password to hash
Hashes the password.
- New hash
You can enter a hash code here, to be put in Active hash.
- Activate hash
Activate the hash code.
All the target (decoder) addresses.
Enables this output line.
The IP address of a decoder.
This IP address must be reachable from the pc on which Stereo Tool runs.
It is possible to send multiple streams to the same encoder for redundancy. See also NIC.
The port address of a decoder.
This port address must be reachable from the pc on which Stereo Tool runs. You will probably need to setup port forwarding in the router on the decoder site.
(TODO: ADD EXPLANATION).
The network interface on the pc to send the data to.
Typically, the operating system will automatically figure out to which network port data needs to be sent to reach the target IP address. But in some cases - especially when using multiple internet providers or links for redundancy - you might want to decide this yourself. If 2 internet providers are available that can both reach the target IP address (or, multiple IP addresses that all point to the same target device), you can decide which data is sent via which provider. The OS will probably choose the same provider for both streams, which would remove much of the redundancy.