01 · Machine learning · Featured project

Teaching a machine to hear rap’s differences.

Outcome: a working web classifier for nine rap subgenres, built from a dataset I assembled and a five-model engineering comparison.

9rap subgenres

5model approaches

1self-built dataset

My roledata → models → interface

Prototype walkthrough18 sec

Why this problem

Rap is not one sound—and treating it that way loses both culture and accuracy.

As a listener and songwriter, I noticed that music apps often recommended the wrong rap style. I also saw a broader stereotype that rap is simply loud or violent. I wanted to build a system that listens for the differences inside the genre.

“Could a model learn the distinctions that listeners—and recommendation systems—often miss?”

The engineering question

Design objective

Classify by musical evidence, not stereotype.

The project required a labeled dataset across nine subgenres, audio features that describe rhythm and timbre, comparable model tests, and an interface that makes the result understandable to a non-engineer.

Evidence to addA short note on how many tracks are in the dataset and how Tony defined each genre label.

How it works

A complete pipeline—from cultural judgment to a usable prediction.

The important technical work was not one model. It was connecting data curation, signal features, fair comparison, and deployment into one system.

Curate

Collect recent rap tracks and label them across nine subgenres.

Manual dataset design

Represent

Convert audio into features that expose rhythm, spectral texture, and timbre.

Mel · MFCC · waveform

Train

Use train/test splits and tune five model families on the same task.

Comparable experiments

Evaluate

Compare behavior across classes—not only a single headline score.

Metrics needed

Deploy

Wrap the selected direction in a web interface people can try.

Working prototype

Visual evidence

Show the system, not just the final screen.

The interface proves the pipeline became usable. The next portfolio pass should add the model comparison chart and confusion matrix so the technical decision is equally visible.

Rap classifier upload interface — **Input:** the web prototype accepts a track for classification.

Rap classification result — **Output:** the interface returns a predicted rap subgenre.

Materials needed for the final pageOne model-comparison table or chart; final test accuracy for each model; a confusion matrix; one screenshot of the dataset or feature-extraction notebook.

Tools + technical decisions

The tool matters only when the reason for choosing it is visible.

Python + Librosa

Read audio, standardize inputs, and extract numerical signal features.

Mel spectrogram + MFCC

Represent low-frequency detail and timbre in forms a model can compare.

SVM · RF · XGBoost · KNN

Compare different assumptions about boundaries, trees, boosting, and similarity.

CNN

Test a deep-learning direction using spectrogram-like visual inputs.

Build the dataset instead of accepting a generic one.

The labels needed to match the rap distinctions the project was trying to preserve.

Compare models horizontally.

Using the same task across five approaches turns “I trained a model” into an engineering choice.

Make evaluation visible.

Overall accuracy alone can hide weak classes. Per-class precision, recall, and confusion are the next required evidence.

Future plan

Move from a convincing prototype to a defensible classifier.

These are proposed next steps, not claims about the current version.

Strengthen the data

Increase examples per subgenre, document label rules, and check class balance and artist leakage.

Measure tradeoffs

Report per-class precision/recall, confusion, inference time, and performance on unfamiliar artists.

Improve the experience

Return confidence and similar styles so the model teaches listeners instead of presenting a label as absolute.