I built MusicPulse to identify songs in YouTube Shorts
Hey everyone,
I’m building MusicPulse, a Chrome extension that identifies songs used in YouTube Shorts.
The problem came from constantly hearing a great track in a Short but not being able to identify it because:
- the audio was sped up or slowed down
- the song was underneath dialogue
- the Short used a reupload or an edited version
- the comments contained the answer, but it was difficult to find
MusicPulse lets you scan the current browser tab after explicit audio permission. It combines audio recognition with video metadata, lyrics, and relevant comment clues. When the evidence is weak, it returns “review needed” instead of confidently inventing an answer.
What I’ve learned so far:
- Audio capture quality matters more than the UI.
- A single comment should never be treated as definitive evidence.
- Reels and Shorts often use versions that are difficult to match against official catalogs.
- Combining independent signals is more reliable than relying on one recognition provider.
- Browser permissions are still one of the biggest UX challenges.
The extension is currently in beta. I’m looking for feedback on:
- scan accuracy
- the permission flow
- false positives and false negatives
- whether this solves a real problem for creators and music listeners
I’m the maker of MusicPulse, and I’d be happy to answer technical questions about the implementation.
Demo video attached.
I’d separate recognition quality from permission-flow failure very early in the beta.
If someone abandons the audio permission step, that is a UX or trust problem. If they complete the scan and receive the wrong song, that is a recognition problem. Combining both into one failed-session metric could send the roadmap in the wrong direction.
I’d also avoid using one global confidence threshold. The cost of a false positive is different for a casual listener and a creator trying to identify music used in their own content.
A lightweight feedback loop could record:
which evidence sources agreed
whether the user marked the result correct, wrong, or uncertain
whether “review needed” led to another attempt
Are you currently storing the evidence combination behind each result, or only the final confidence score?
That’s a very useful distinction, and I agree they should not be treated as one failure.
In beta, we separate permission/capture problems from recognition outcomes in our diagnostics. Results also retain high-level evidence and confidence context, while user feedback helps distinguish correct, wrong, and uncertain matches.
One metric we’re especially interested in is what happens after “review needed”: whether users retry, confirm a result, or abandon the scan. Thanks for the thoughtful suggestion.
That sounds like the right instrumentation for an early beta.
The one metric I’d be careful with is retry rate on its own. A high retry rate could mean users are engaged, but it could also mean the “review needed” state is confusing or not giving them a clear next step.
I’d pair it with a resolution metric: after “review needed,” did the session end in a confirmed match, a corrected result, or abandonment?
That should show whether the state is actually helping users recover rather than simply delaying a failed outcome. Glad to hear you’re separating these layers this early.
That’s a great distinction. Retry rate alone could definitely be misleading, especially if “review needed” doesn’t give users a clear path forward.
We’ll pair it with the outcome after the state: confirmed match, corrected result, or abandonment. That should tell us whether the feature is helping users recover or simply postponing failure.
Thanks for the thoughtful feedback.
I like that the product is willing to say "review needed" instead of pretending certainty.
Knowing when the available evidence isn't enough can be just as valuable as recognizing something correctly. That tends to create more trust over time than always producing an answer.
Exactly. That’s one of the principles behind MusicPulse: a cautious “review needed” is better than a confident wrong answer.
We’re still tuning the confidence thresholds in beta, but protecting user trust matters more than forcing a result every time. Thanks for pointing that out.
I appreciate you taking the time to explain your thinking.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
Sure. You can reach me at music.pulse.dev@proton.me.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.