cd /news/machine-learning/building-a-music-brain-my-youtube-da… · home topics machine-learning article
[ARTICLE · art-74372] src=promptcube3.com ↗ pub= topic=machine-learning verified=true sentiment=· neutral

Building a Music Brain: My YouTube Data Workflow

A developer is building a multi-month YouTube data workflow that uses a browser extension to capture implicit listening signals—such as skipping a track after four seconds or looping a chorus—and processes them through a FastAPI backend, PostgreSQL storage, and an offline ML pipeline to generate personalized playlists. The system classifies videos, resolves metadata, analyzes audio embeddings with mood tagging, and stores vectors in pgvector for similarity searches, aiming to achieve a level of personalization beyond generic algorithms.

read2 min views1 publishedJul 26, 2026
Building a Music Brain: My YouTube Data Workflow
Image: Promptcube3 (auto-discovered)

This isn't a quick weekend build. It's a multi-month deployment involving a browser extension for data collection, a backend for storage, and ML pipelines for analysis. The core goal is to capture "implicit signals"—the things I do without thinking, like skipping a track after four seconds or looping a specific chorus—and translate those into a behavioral profile.

The Data Pipeline Architecture #

To make this work, the system has to track the lifecycle of a single song from the moment I click it to the moment it influences a playlist.

  1. Data Acquisition (Browser Extension)

A content script monitors the YouTube video element. Instead of just tracking "views," it acts as a stenographer, recording timeupdate

, ``

, seeked

, and ended

events. This allows the system to calculate the actual watch percentage and identify specific segments I find appealing.

  1. Ingestion (Event API)

To avoid over the server, the extension batches these observations into JSON payloads and POSTs them to a FastAPI backend:

{
  "video_id": "xyz123",
  "title": "Artist - Song Name",
  "channel": "OfficialChannel",
  "watch_segments": [[0, 41], [132, 222]],
  "timestamp": "2023-10-27T21:47:00Z",
  "session_id": "sess_98765"
}
  1. Storage (PostgreSQL)

The raw events are written directly to PostgreSQL. I keep the raw signal intact because any future changes to the ML logic will require re-processing the original data.

  1. Processing (Offline ML Pipeline)

This is where the "forensic" work happens. A nightly pipeline processes the raw events to:

Classify: Confirm if the video is actually music.Resolve: Parse titles and use external lookups for clean metadata.Analyze: Use audio embeddings and mood tagging to determine the "vibe."Score: Convert watch percentages and replay counts into implicit ratings.

Indexing (Vector Store)

The final step involves pushing audio embeddings into

pgvector

. By storing these as vectors alongside relational metadata, the system can perform similarity searches to find songs that match the specific "fingerprint" of my late-night synthwave sessions or morning lo-fi habits.This setup transforms a messy history page into a structured AI workflow, allowing for a level of personalization that generic algorithms usually miss.

Next Swarmvault: A Lean LLM Agent Workflow →

── more in #machine-learning 4 stories · sorted by recency
── more on @youtube 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/building-a-music-bra…] indexed:0 read:2min 2026-07-26 ·