Memories.ai ships O-MARC: how to make audio-visual AI faster, cheaper, and more accurate at once
- AI that watches video and listens to audio at the same time sits at the frontier of video understanding, but a single second of video eats up a huge number of tokens. The cost of running multiple camera feeds continuously is the main reason this class of model has stayed stuck in the lab.
- Memories.ai's O-MARC does the "smart discarding": it keeps only the key frames and audio anchors relevant to the question and throws the rest out as noise, cutting inference time by 34.6% (1.53x faster) and memory use by 34.7%.
- Compression usually trades accuracy for speed. This method claws the accuracy back with a distillation trick — the same model answers the same question twice, once "open-book" and once "closed-book" — pushing the average across four benchmarks to 45.8, above the uncompressed baseline's 44.1.
- The compression module, OMAC, is training-free and drops in front of an already-deployed model. Getting the higher accuracy score requires an extra round of reinforcement-learning training on top.
- The companion benchmark, UGC-AVQA, covers 1,000 videos and 4,816 questions. Every candidate question is first tested with the audio track deleted; anything the AI can still answer gets cut, leaving only questions that genuinely require hearing.
On July 8, Memories.ai released a piece of research called O-MARC (the companion paper had already gone up on arXiv on May 26). It tackles a very specific problem: how to make AI that processes video and audio together run faster, cheaper, and more accurately all at once.
Today's audio-visual AI is stuck on two problems
1. It's too expensive and too slow — the compute bill doesn't add up
A model doesn't "watch" a video directly. Before it goes in, the video gets chopped into a long string of tokens: each frame is sliced into many chunks, one chunk per token; audio is sliced by time into a run of tokens; then your question gets tacked on. The three pieces are strung together into one long sequence, and the model reads through it from start to finish.
The longer that sequence, the more memory and time it costs. Both video and audio are unusually token-hungry modalities, so stacking them together roughly doubles the sequence length.
Diagram (drawn by this site). Dark orange blocks are frame tokens, lighter blocks are audio tokens, dark gray is text. A 32-frame short clip alone already runs to a few thousand tokens.
A real measurement from the paper: even capped conservatively at one frame per second and 32 frames per clip, running a single clip (the 64-frame setup) on the long-video benchmark WorldSense takes 3.81 seconds and 24.2GB of memory. A single GPU running one stream alone is nearly maxed out.
Multiply those two numbers by the number of camera feeds and hours of runtime, and it's clear why scenarios that need 24/7 multi-feed video — surveillance centers, factory floors — have found the cost prohibitive.
2. Benchmarks that don't actually measure what they claim to
Say you're evaluating two video-analysis systems, both claiming to understand video and audio together. You run them on an off-the-shelf audio-visual benchmark: system A scores 70, system B scores 60. The question is — how much of A's 70 actually came from listening?
Most audio-visual benchmarks can't answer that. A large chunk of their questions are guessable from the picture alone — a car crash, someone falling, a machine smoking — none of which require sound to identify. A model that ignores audio entirely can still post a good score, which turns "joint audio-visual understanding" into something nobody can actually verify at the benchmark level.
Say you want to hire someone who knows English. The test you give them is all multiple choice, and three of the four options in every question are obviously grammatically wrong. Someone who doesn't know English can still score 80 by process of elimination. That test isn't measuring the skill you actually care about.
For anyone buying this kind of system, that means there's no reliable way to tell which vendor genuinely integrated audio and which one just bolted it on for show. The industry has been missing a test that can actually verify "it really understood what it heard."
Memories.ai's two co-founders, Shawn Shen and Ben Zhou, both came out of Meta, where they worked on the AI system behind Meta's Ray-Ban smart glasses. Along the way they ran into an unavoidable problem: the glasses record constantly, but users could never pull anything back out of that footage — the AI saw it but couldn't remember it. That pain point is what pushed them to leave and found Memories.ai in 2024, dedicated to turning video into something that can be searched and recalled. O-MARC is the latest step on that path.
How OMAC picks which frames and sounds to keep
First, the official animation — 37 seconds, three points.
Three names show up in that animation, and it's easy to mix them up — here's what each one actually is.
The common approach to compression is uniform pruning: downsample every frame equally, sparsify every audio segment equally. The problem is that video is full of redundancy — the same background can repeat for dozens of frames — while audio might have only a split second that's actually decisive. A blanket cut wipes out the redundant background and the key evidence together.
OMAC picks its priorities in four steps.
Average all the tokens within a frame into a "summary" for that frame, then measure its similarity to your question — high-scoring frames get kept. It's not scoring alone, though; the method also balances coverage across time, so the kept frames don't all bunch up near the start of the clip.
Measure how far each token deviates from that frame's average, and keep the ones with the biggest deviation. Tokens that match the average closely are probably repeated background; tokens that stand out are more likely to capture what's actually happening in that frame. The tokens that survive, plus one or two "frame memory tokens" formed by weighting and summarizing them, go back into their original position in the timeline.
Audio is scored by importance, and the highest-scoring segments become anchors. Nearby tokens that get dropped are folded into the nearest anchor by a merge weight. So an anchor isn't just carrying its own information — it absorbs a slice of what's around it, which means voice cues and ambient sound don't vanish outright.
After frame compression, some moments in time end up with a lot of surviving frames and tokens, while others have almost none. OMAC treats that density as a signal for "how important is this moment," and uses it to reallocate the audio budget accordingly — denser moments get more listening budget, sparser moments get compressed harder. The total budget stays the same; it just gets redistributed.
Step four is the crux of the whole design, and the biggest thing that sets it apart from other compression methods. The paper ran a direct comparison of three "who guides whom" variants.
Even when visual signal is the one doing the guiding, pruning it first before using it to allocate audio beats using the raw visual signal directly by 1.7 points. Raw video carries a lot of repeated background, and using it unfiltered to judge which audio matters lets that noise leak straight into the decision.
Unfiltered frame information is used to judge which audio segments matter, so repeated background gets a say in the decision too.
Frames relevant to the question get picked out first, and only then does the method look at where they're dense. By this point the density itself reflects an already-filtered judgment.
Diagram (drawn by this site). The top row is the surviving frames after pruning; the bottom row is the audio budget assigned to each corresponding time slice.
Training-free — just drop it in
This part of OMAC doesn't touch the underlying model and needs no retraining; it plugs in as a preprocessing step in front of a model that's already deployed. For teams already running a full omni-modal model in production, that means no rebuilding the training pipeline and no re-running a launch process.
Faster without getting dumber: how accuracy goes up after compression
Compression usually costs accuracy, because the model was originally trained with full material and doesn't adapt well when you suddenly hand it 30%. O-MARC's training stage exists specifically to make up that gap.
The key is that the teacher and student are the same model, at the same moment, with the same set of parameters. It answers the same question twice: once with the full material, once with the compressed material. The size of the score gap between the two runs tells you how badly that particular question got hurt by compression.
The same student does the same question twice — once open-book, once closed-book. Whichever questions drop the most going from open-book to closed-book get flagged for extra practice. But only if the student had a real shot at getting it right in the first place — a question they were never going to get right regardless doesn't get extra practice just because closed-book made it worse.
The mechanics live inside reinforcement learning's "advantage value" — a per-answer score that tells the model how much better this attempt was than others in the same batch, which is what it uses to decide which direction to adjust in. O-MARC multiplies "advantage is positive" by "how much this sample fears compression" to get an extra weight, then adds that back into the advantage value scaled by a tunable strength coefficient. Only samples where both conditions hold get a meaningfully larger weight.
The teacher branch passes its preference to the student by rewriting this advantage value, rather than aligning token-by-token probabilities, pushing the model toward the kind of behavior that stays stable after compression. The entire training run used just 3,000 samples and four GPUs with 96GB of memory each.
The final numbers
| Configuration | Average across four benchmarks | vs. uncompressed |
|---|---|---|
| Uncompressed, full tokens | 44.1 | — |
| OmniZip (existing compression method) | 41.0 | −3.1 |
| OMAC (training-free plugin) | 42.8 | −1.3 |
| O-MARC (OMAC + training) | 45.8 | +1.7 |
The base model is Qwen2.5-Omni-3B, with a 30% retention ratio and 32 frames. The four benchmarks are DailyOmni (everyday-video audio-visual understanding), UGC-AVQA (the new one released here), OmniVideoBench (long-video reasoning), and WorldSense (real-world composite perception). The 45.8 figure is the average across all four; broken out, UGC-AVQA sees the biggest gain while the other three land roughly flat or slightly below the uncompressed baseline. The efficiency figures come from a separate experiment using 64-frame long videos.
The advantage grows the harder you compress. At 70% compression on UGC-AVQA, OMAC still holds 49.2 points while OmniZip drops to 47.1. The less material you keep, the more "keeping the right material" matters.
UGC-AVQA: a benchmark built by deleting the audio track and re-testing
Proving a model genuinely listens requires a test it can't pass without listening. This benchmark's filtering method comes down to a single step.
For every candidate question, the audio track is stripped entirely and Gemini-3.1-Flash answers with visuals alone. Any question it gets right is thrown out; only the ones it can't answer survive.
What's left can't be answered from the picture alone. The full benchmark covers 1,000 user-uploaded short videos and 4,816 question-answer pairs across four categories: audio-visual event progression, scene or time transitions, cross-scene alignment, and fine-grained comparison. Every video has a detailed human-written "omni-modal description" covering people and objects on screen, scene changes, actions, sound events, and temporal relationships; 30% of both the candidate questions and the generated training questions were spot-checked and corrected by trained annotators.
What the questions actually look like
Four real examples make it clear.
How did the tone of people's voices change right as the air fryer started spinning?
Answer: they sounded surprised
Which pronoun was the teacher pointing to on the wall the first time their voice warned against using the informal form of address?
Answer: vosotros (the informal Spanish "you all")
How did the keyboard's backlight color change between when this person first asked the question and when they later explained it?
Answer: blue to purple
What sound played right before the camera cut to the box?
Answer: a woman asking a question
The third question, about color, looks purely visual — but "first asked" and "later explained" are two points in time that can only be located by listening. This category tests whether the two channels line up; watching alone or listening alone can't answer it.
How did models actually do? Across nine models tested, the top score was Gemini-3.1-pro at 69.1; the largest open-source model, Qwen3-Omni-30B-A3B, scored 65.0; and Qwen2.5-Omni-3B, the base model used in this work, scored only 49.0. Most open-source models' weakest category was cross-scene audio-visual alignment — the same type as the vosotros question above — where even Qwen3-Omni-30B-A3B only managed 60.9.
| Model | UGC-AVQA average |
|---|---|
| Gemini-3.1-pro | 69.1 |
| Gemini-3.1-flash-lite | 67.1 |
| Qwen3-Omni-30B-A3B | 65.0 |
| Gemma-4-E4B-it | 59.7 |
| Gemma-3n-E4B-it | 54.6 |
| Qwen2.5-Omni-7B | 54.2 |
| Gemma-3n-E2B-it | 53.0 |
| Qwen2.5-Omni-3B (base model used here) | 49.0 |
| Gemma-4-E2B-it | 45.6 |
Data from paper Table 2. Gemini-3.1-pro and flash-lite were the models being scored on the leaderboard; Gemini-3.1-Flash, a different variant, served as the judge that filtered the questions in the first place. Also worth noting: getting a question wrong while silenced shows it isn't solvable from visuals alone, but ambiguous phrasing, poorly designed distractors, or a model's own limitations can also cause a wrong answer — those questions get kept too.
Where that saved third can actually go to work
Cutting both latency and memory by roughly a third means, in practical terms, the same machine can now handle more cameras and more simultaneous live streams.
Security operations centers, factory floors, retail stores, and smart buildings all need to watch dozens of live feeds at once — cutting the cost is what makes it feasible to plug an omni-modal model into that pipeline in the first place.
Unusual equipment noise, someone shouting for help, sound that starts before the corresponding motion appears on screen — these events can't be caught by watching alone. They require both channels together, and the model genuinely has to be listening.
When extracting metadata from huge video libraries, being able to tag what happened in the audio, not just what's on screen, directly affects the quality of later search and retrieval.
Automated pipelines that alert, route, tag, or escalate the moment an event is detected — a 1.53x speedup can turn scenarios that used to be "too slow to run in real time" into something usable.
One more: instructional and training video
The key content in a course video often lives in what's being said, not what's on screen. A slide might just be a static image while the real information comes out of the instructor's mouth. Content understanding, quality assessment, and knowledge extraction for this kind of material require genuine joint audio-visual reasoning — watching alone won't surface anything useful.
The use cases above come from Memories.ai's own research page. The paper itself doesn't include any deployment experiments — every result was measured on Qwen2.5-Omni and Qwen3-Omni benchmarks.
What you can get your hands on right now, and what you still can't
If you want to try this yourself, here's what checking things directly turned up.
One more note: the released dataset ships the original video links and annotations, not the video files themselves. The authors state in the paper's limitations section that some portion of the data will inevitably go dead over time as platform content changes — a common problem for any short-video dataset that depends on external links.
These results suggest that audio-visual compression shouldn't be treated merely as an inference-speedup trick — it's also a trainable condition pointing toward more robust, more efficient omni-modal reasoning. Paper, conclusion section
What this research lands on is turning "smart discarding" from an inference-time trick into a trainable objective. The code is public; the data and weights are still pending.
Getting AI to watch and listen to video: from swallowing everything whole to keeping only the right 30%
Memories.ai's O-MARC: 1.53x faster inference, a third less memory, and slightly higher accuracy on top — the whole thing in one page, with a diagram.
↓ Read to the end · one diagram animates
This piece is about a class of AI that can watch video and listen to audio at the same time — the paper calls it an omni-modal model. It has one extra "ear" that a vision-only model doesn't: if a sound comes first and the camera only cuts to it afterward, this kind of model can connect the two. What holds it back is cost.
✘ Processing one minute of video takes 3.81 seconds and 24.2GB of memory (where data gets staged on the GPU) — running several camera feeds at once just isn't sustainable
Before it reaches the model, a video gets sliced into one long string of tokens (the smallest unit a model reads — one small chunk of picture, or one short segment of sound, each counts as one). Both video and audio are unusually token-hungry, and stacking the two streams together roughly doubles the sequence length — the longer that sequence, the more memory and time it costs. This is the main reason this class of model has stayed stuck in the lab.
Memories.ai's approach is "smart discarding": out of the long input string that video and audio get converted into, only 30% is fed to the model — the rest is thrown out as noise. Which 30% gets kept is where all the work is.
A blanket cut: downsample every frame equally, sparsify every audio segment equally. But video is full of repeated background, while audio might have only a split second that's actually decisive. The repeated background and the key evidence get cut together, and the score drops with them.
Look at the question first, then pick out the specific frames and audio segments that matter for it. Discarded audio gets folded into the nearest surviving key segment by merge weight, so the information stays attached to those segments.
The release also comes with a new benchmark, UGC-AVQA, built specifically to fix the hidden problem above: every candidate question has its audio track stripped entirely, and a strong model answers using visuals alone. Anything it gets right is thrown out — only what it can't answer survives. What's left can't be answered straight from the picture.
Keeping just 30% means one wrong cut and the answer is gone. So everything hinges on the order in which things get picked.
Picking happens in four steps: score every frame against the question first and pick the relevant ones, then within those frames keep whatever looks least like the background. On the audio side, keep a few key segments and fold whatever's discarded into the nearest one. Step four is where this method pulls ahead of everyone else — it looks back at where frames were kept densely versus sparsely on the timeline, and uses that density to reallocate the audio budget.
Diagram (drawn by this site). Moments with denser surviving frames get more listening budget; sparser moments get compressed harder, with the total budget unchanged. Bottom half compares three orderings: pruning frames clean first and then using them to allocate audio beats using raw, unfiltered frames by 1.7 points — raw video carries a lot of repeated background, and using it unfiltered to judge which audio matters lets that noise leak into the decision. Scores are from a daily-video benchmark (DailyOmni).
The official numbers are percentages. Converted into what a machine would actually have to do, it's easier to feel: say there are 1,000 roughly one-minute surveillance clips to process.
Based on the paper's measured 3.81 seconds vs. 2.49 seconds per clip (roughly one-minute clips, 64-frame configuration), scaled to 1,000 clips — a 22-minute difference, matching the 1.53x figure exactly. Memory drops by the same third, from 24.2GB to 15.8GB; estimated (for illustration) against an 80GB card, that's the difference between fitting three camera feeds and fitting five. All figures above are self-reported by Memories.ai and its academic co-authors; the paper went up on arXiv in May and this site found no third-party reproduction. As of July 21, the companion benchmark and trained model weights still hadn't been released — only the compression code is public.
One thing that's easy to conflate: the training-free plugin used on its own scores 42.8, a bit below the uncompressed 44.1, in exchange for a third off both speed and memory. Getting to that higher 45.8 score requires a follow-up training round — 3,000 questions, four GPUs with 96GB of memory each. Drop it in and use it and drop it in and get more accurate are two different deals.
one one-minute
clip takes
the baseline's approach
guide audio, mixed
with repeated background
Members can copy or download the full Markdown, and let their AI subscribe and ask.
Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.
