Initializing... drag & drop files here
Supports: RM
RM is RealNetworks' RealMedia container from the RealPlayer streaming era — a proprietary wrapper around the RealVideo and RealAudio codecs. This page reads the RealAudio track inside an .rm file, discards the picture, and re-encodes the sound as M4A — AAC audio in an MPEG-4 container, the format Apple Music, iOS, Android and every current desktop player treat as a default.
.rm file onto the page or click "+ Add Files". Several files can be queued and they run with the same settings..m4a. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark.RealMedia carried a whole family of RealAudio codecs across its lifetime, and which one you have decides how much bitrate is worth spending on the M4A. Every RealMedia file opens with the four-byte signature .RMF. Decoder support below is from the FFmpeg documentation, which is the decoding lineage this conversion runs on; the sample rates are from real RealMedia files measured for this page.
| RealAudio codec | Typical use | Rates seen in real files | Decodes here |
|---|---|---|---|
| RealAudio 1.0 (14.4) | 1990s dial-up voice | 8 kHz mono | Yes |
| RealAudio 2.0 (28.8) | dial-up music and voice | varies | Yes |
| Cook (RealAudio G2) | the most common in the files tested here | 8 kHz mono at 6 kbps; 44.1 kHz mono at 65 kbps | Yes |
| SIPR / ACELP.NET | speech-only streams | 8 kHz mono at ~5 kbps | Yes |
| RealAudio Lossless (RALF) | the lossless variant | varies | Yes |
| AAC | listed by the Library of Congress as a RealAudio 10 subtype | varies | Yes |
The Audio Codec group on this page shows a single entry, AAC, because that is the only codec an .m4a container is written with here. There is no codec choice to make.
This is a lossy-to-lossy re-encode, so spending more bitrate than the RealAudio track ever carried buys nothing but file size. Measured on a real RealMedia capture whose Cook track is 44.1 kHz mono at 65 kbps and runs 16.7 seconds:
| Setting | Output size | Effective rate |
|---|---|---|
| Quality Preset — Lowest / Very Low | 110,193–114,488 B | ~53–55 kbps |
| Quality Preset — High / Medium | 122,065 B | 58.5 kbps |
| Quality Preset — Very High | 156,301 B | 74.9 kbps |
| Quality Preset — Highest | 215,916 B | 103.4 kbps |
| Custom Bitrate 64 kbps | 141,223 B | 67.6 kbps |
| Custom Bitrate 128 kbps | 274,758 B | 131.6 kbps |
The 128 kbps result is more than double the size of the 65 kbps source for no audible gain. The presets are not evenly spaced either: High and Medium land on the same internal quality rung, as do Very Low and Lowest, so stepping one notch does not always change the file.
Yes. The decode happens on our servers on the FFmpeg/libavcodec lineage, which documents decoder support for RealAudio 1.0, 2.0, 3.0, Lossless and SIPR, plus every RealVideo generation. Nothing needs installing and the .rm uploads as-is. The Library of Congress format registry describes RealVideo and RealAudio as proprietary with little public documentation — which is exactly why moving the audio into AAC is worth doing while working decoders still exist.
No. RealAudio is lossy and AAC is lossy, so this is a second lossy generation on top of the first. What you gain is portability, not fidelity. The way to keep the second generation cheap is to pick a bitrate at or a little above the source rate — for the 65 kbps Cook sample above, the Very High preset at 74.9 kbps is the sensible ceiling.
Because the source is 8 kHz. At an 8 kHz mono sample rate the AAC encoder physically cannot spend 128 kbps — asking for it on the two 8 kHz RealAudio samples measured here produced roughly 48–50 kbps of actual output. Rather than fight it, leave the sample rate on the source value and use a preset; a speech-rate RealAudio stream has nothing more to encode.
The .rm probably has no audio track. RealMedia was often authored video-only to save bandwidth, and one of the four RealMedia samples tested for this page is exactly that: a RealVideo 3.0 stream with no audio stream at all. An audio-only target has nothing to write, so the job fails outright rather than producing a silent file. Check by converting the clip with RM to MP4 and seeing whether the result has sound.
Some RealMedia files store their audio in interleaved blocks whose packet timestamps do not run in order. When that happens the audio samples all survive, but the duration written into the M4A header can come out short. On the SIPR sample measured here the header declares 97.7 seconds while the file decodes to 112.4 seconds of audio that matches the source level-for-level throughout. Players that decode to the end play everything; players that trust the header show a short seek bar. If that matters, convert to a video target such as RM to MKV instead, where the duration comes out correct, or re-encode the M4A afterwards.
AAC delivers more quality per bit than MP3 at the same rate, and M4A is the native audio container across Apple devices. For a RealAudio source that is already thin, that efficiency edge matters more than usual. If you want the single most universally playable file — car head units, old hardware, anything with a USB port — take RM to MP3 instead. If you want to keep the picture too, use RM to MP4.
Audio only. This page writes an .m4a, so any RealVideo stream in the file is dropped. That is what you want for lectures, interviews, internet-radio captures and music, and it is why the output is a fraction of the original file size.
Yes, with the Trim control on this page: it takes a start time and a duration, prefilled at 0 and 10, and applies them to the source before the encode so you are not paying to encode material you will delete. If you would rather cut after the fact, run the finished M4A through Audio Cutter — that tool works on audio files, not on the original .rm.
It is uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public. RealMedia files are usually small because the format targeted dial-up bitrates, so upload time is rarely the bottleneck.