EasyEar Video

Inspiration

EasyEarVideo was inspired by people who experience sensory sensitivity, anxiety, migraines, or discomfort when online videos suddenly become much louder. Promotional sections, music transitions, and sound effects can interrupt an otherwise comfortable viewing experience.

My inspiration for the project came when I wanted to mute the TV I had playing for my dog, when it was playing ads. I began down that road and realized I consume way more content in Youtube and would like to mute ads automatically that come on and startle me.

The project is not an ad blocker. It is an accessibility concept that explores how video players could reduce abrupt loudness changes without forcing viewers to constantly adjust their volume.

What It Does

EasyEarVideo embeds a YouTube video and demonstrates adaptive audio comfort. When playback reaches a predefined “loud” segment, the app:

Identifies the segment and displays its confidence score
Smoothly reduces the embedded player’s volume
Restores the previous volume when the segment ends
Records both changes in an event log

Users can adjust normal and reduced volume levels, enable or disable Adaptive Audio, and trigger a five-second simulation.

How I Built It

I had codex build EasyEarVideo with:

Vite
React
TypeScript
Plain CSS
YouTube IFrame Player API
Browser localStorage

For a reliable Build Week demo, the detection layer uses predefined timestamps instead of microphone access, machine learning, or a backend. The app polls the video’s playback position, compares it with configured loud segments, and gradually changes the embedded player’s volume.

The interface was designed mobile-first with large touch targets, clear status cards, high contrast, and a calm visual style.

Challenges

The biggest challenge was platform-level audio control. The YouTube IFrame API supports player-volume changes in desktop browsers, but iOS does not allow embedded YouTube players to programmatically control their volume. The interface and detection experience work on an iPhone, but the audible volume reduction must currently be demonstrated on a supported desktop browser.

Another challenge was coordinating automatic timestamp detection with the manual simulation. Initially, the timestamp polling loop could cancel a simulated segment early. I separated manual simulations from automatic detection so the five-second demonstration now runs reliably.

What I Learned

I learned that accessibility-focused ideas must account for browser, device, and media-platform restrictions early in development. A feature can work correctly through a web API on desktop while behaving differently on mobile.

I also learned the value of building a deterministic prototype first. Predefined segments made it possible to validate the complete user experience—detection, feedback, fading, restoration, and history—before investing in real audio classification.

What’s Next

The next step is a native iPhone proof of concept using authorized, app-owned media and Apple’s native playback framework. That would allow reliable player-level volume control on iOS.

Future versions could add: