Memories.ai ships O-MARC: how to make audio-visual AI faster, cheaper, and more accurate at once

The release also comes with a new benchmark that deletes the audio track and re-tests every candidate question — anything a model can still answer by sight alone gets thrown out.
By Memories.ai Research07-21 · 12 min read⚑ Research paper
🎧 Listen to the podcast0:00 / --:--
0:00 / --:--
Research breakdown · XiaoHu Explains
60-second version
  • 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.
⚑
Sourced from Memories.ai's research page and its arXiv paper; efficiency and accuracy figures are the authors' own self-reported results. Numbers in this piece have been checked against the paper's tables for their applicable conditions, and any differences are flagged.

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.

The pain point

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.

How a video turns into one long string of tokens
Frames (one per second, up to 32 per clip) Each frame sliced into many small chunks Audio (16kHz, sliced by time) The question you asked Strung into one sequence fed to the model · Longer sequence = more memory, slower output …and on

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.

3.81 sec
Time to process one long video clip, uncompressed
24.2 GB
Memory the same clip consumes

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.

An analogy

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.

Breakthrough one

How OMAC picks which frames and sounds to keep

First, the official animation — 37 seconds, three points.

Memories.ai's official 37-second animation. The captions read, in order: "First, O-MAC," "a third less memory" (labeled Qwen-Omni-3B), and "UGC-AVQA, a benchmark that forces models to truly hear and see." This is a concept animation, not a screen recording of the model running; "a third less" is a rounded figure — the paper's actual number is 34.7%. Source: @memories_ai, 2026-07-20

Three names show up in that animation, and it's easy to mix them up — here's what each one actually is.

OMAC
The compression module: training-free, drops in front of an already-deployed model, and handles picking which frames and sounds to keep.
O-MARC
The full framework: OMAC plus a round of reinforcement learning that teaches the model to stay accurate even after its material has been compressed.
UGC-AVQA
The companion benchmark released alongside it, built to verify whether a model is truly listening rather than just watching.

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.

OMAC mechanism diagram
OMAC's four steps. On the left, the outputs of the video, audio, and text encoders feed into OMAC; the green box on the right runs, left to right, through frame scoring, visual memory, audio memory, and using visual memory to allocate the audio budget. Source: paper Figure 2
1
Score every frame first, and pick out the ones relevant to the question

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.

2
Within the chosen frames, keep whatever looks least like the frame's own average

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.

3
Keep a few audio anchors; discarded audio merges into them

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.

4
Use how densely frames were kept to steer the audio budget

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.

Audio guides visual compression
the baseline OmniZip's approach
47.7
Raw visual signal guides audio directly
48.2
Build both memories first, then use visual memory to set the audio budget
OMAC's final design
49.9

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.

Using raw visual signal directly

Unfiltered frame information is used to judge which audio segments matter, so repeated background gets a say in the decision too.

Pruning first, then using it

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.

What step four actually looks like
After pruning, some time segments have a lot more surviving frame memory than others Time → Audio budget gets reallocated to match that density, with the total budget unchanged more tight more tight Total budget doesn't grow. Whatever the dense moments gain, gets pulled from the sparse ones.

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.

Breakthrough two

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.

O-MARC training framework diagram
During training, the same question produces two answers: the yellow branch on top is the teacher, fed the full token set with no compression; the blue branch below is the student, working from OMAC-compressed material. Each branch computes its own reward, and the gap Δ between them feeds into the compression-aware module in the bottom right, which combines with the reinforcement-learning advantage to produce a new advantage value. Source: paper Figure 3

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.

An analogy

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

ConfigurationAverage across four benchmarksvs. uncompressed
Uncompressed, full tokens44.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
34.6%
Drop in inference latency — roughly 1.53x faster
34.7%
Drop in memory use, from 24.2GB down to 15.8GB

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.

If you're thinking about dropping OMAC straight into a production model: the training-free tier scores 42.8 in this set of experiments, a bit below the uncompressed 44.1, in exchange for a third off both speed and memory. Reaching the higher 45.8 score requires a follow-up round of reinforcement-learning training.
Breakthrough three

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.

Silent test

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.

Four-panel diagram of the UGC-AVQA construction pipeline
The construction pipeline in four steps: collect 1,000 UGC videos, have humans annotate the four categories of audio-visual questions, strip the audio track and use Gemini 3.1 Flash to filter out the hard samples, and use the remainder as training data. The diagram notes the filtered hard-sample set at 206 videos and 1,648 questions, forming the eval set; the remaining 794 videos and 3,168 questions are used for training. Source: paper Figure 1

What the questions actually look like

Four real examples make it clear.

Event progression

How did the tone of people's voices change right as the air fryer started spinning?

Answer: they sounded surprised

Cross-scene alignment

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")

Fine-grained comparison

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

Scene and time transition

What sound played right before the camera cut to the box?

Answer: a woman asking a question

Four example UGC-AVQA question types
The original figure for the four questions above, from the paper, with correct answers highlighted in green. Source: paper Figure 5

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.

ModelUGC-AVQA average
Gemini-3.1-pro69.1
Gemini-3.1-flash-lite67.1
Qwen3-Omni-30B-A3B65.0
Gemma-4-E4B-it59.7
Gemma-3n-E4B-it54.6
Qwen2.5-Omni-7B54.2
Gemma-3n-E2B-it53.0
Qwen2.5-Omni-3B (base model used here)49.0
Gemma-4-E2B-it45.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.

Related on this site
Gemma 4 technical report: how a small open model tries to out-muscle bigger ones with fewer parameters, reasoning, and lower memory use
What it's good for

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.

📹
Multi-camera surveillance and security

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.

🔊
Detecting sound-and-sight anomalies

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.

🏷️
Video library tagging and search

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.

⚡
Real-time triggered automation

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.

Current state

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.

OMAC code
Already public. The official repo WPR001/Omni_marc has a complete implementation — about 950 lines for the core compression logic plus roughly 4,300 lines of model modifications — along with a reproduction of the baseline OmniZip method and two trainers. The repo root still doesn't have a LICENSE or install instructions.
UGC-AVQA benchmark
Not yet released. The repo's most recent update, from June 23, 2026, reads "benchmark and training data is coming soon." As of a check on July 21, 2026, the dataset still hadn't appeared under the Memories-ai account on HuggingFace.
Trained model weights
Not yet released. The three models currently under that same account are UGC-VideoCaptioner, security_model, and the prior-generation MARC (memory-augmented reinforcement-learning token compression, visual-only) — none of them are from this release.
What it takes to train it yourself
Four NVIDIA RTX PRO 6000 GPUs (96GB of memory each), a Qwen2.5-Omni-3B base model, and 3,000 training samples.

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.

Source
O-MARC: Faster, More Accurate Audio-Visual Video UnderstandingMemories.ai·memories.ai/research/O-MARC·2026-07-08
Editor's note
The four mechanism and example figures are from paper Figures 1/2/3/5; the video is from the official post. The two token-sequence and audio-budget diagrams were drawn by this site, as noted. Figures in this piece were checked against the paper's Tables 2/3/4/6/7 for their applicable conditions: 45.8 and 44.1 come from the 3B, 32-frame, 30%-retention configuration; 34.6% and 34.7% come from the 64-frame long-video efficiency experiment — the two sets of conditions differ. Release status for the dataset and model weights reflects a check of GitHub and HuggingFace on 2026-07-21. Company funding and partnership details are from TechCrunch reporting.
↑ End of article
✓ This article is free to read in full

Members can copy or download the full Markdown, and let their AI subscribe and ask.

Read the original ↗
📮 New explainers, straight to your inbox

Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.