Music Recommendation System

The main problem is to recommend a personalised list of tracks from a large catalog when user preferences may be incomplete, new users have little interaction history, and newly added songs have few or no interactions.

1.2 Objectives

• Design a modular music recommendation pipeline for user profiles, track metadata, and interaction history. • Combine content-based similarity with collaborative preference signals. • Address cold-start scenarios for new users and new tracks. • Evaluate ranked recommendations with top-K metrics and catalog-level measures. • Include privacy, diversity, and user feedback in the system design. 1.3 Scope The system is intended as an academic prototype for recommending tracks from a permitted dataset or a locally maintained catalog. It may use user ratings, plays, likes, skips, and playlist actions. It does not require access to private streaming-platform accounts. Any third-party API integration must follow its terms of service and protect user credentials.

Recommender-system research commonly distinguishes collaborative filtering, content-based filtering, and hybrid approaches. Collaborative filtering identifies patterns among users or items from interactions. User-based methods find listeners with similar behaviour, while item-based methods recommend tracks that are frequently consumed by similar audiences. Matrix factorization represents users and items in a lower-dimensional latent space and has been influential in rating-prediction and implicit-feedback settings. Content-based recommendation relies on item descriptions and user profiles. For music, descriptive features can include artist, genre, language, release year, and audio attributes such as tempo or energy when legitimately available. This approach can recommend a new track even before it receives many interactions, provided its features are known. However, it may overspecialise by repeatedly suggesting tracks similar to those already consumed. Hybrid systems combine multiple signals to reduce the weaknesses of individual approaches. The Netflix Prize demonstrated the practical importance of collaborative methods at scale, while the broader recommender-systems literature describes evaluation, user modelling, diversity, and cold-start challenges. Music recommendation has additional context-specific issues: listening can be mood-dependent, short previews may not represent full preferences, and repeated exposure can influence future behaviour.

A system optimised only for predicted preference can produce repetitive or popularity-dominated results. The proposed design treats ranking quality as multi-dimensional: relevance is measured alongside diversity and catalog coverage, and new-user fallback recommendations are explicitly included.

The proposed system builds a user profile from explicit feedback and implicit events. A content module compares track features with the profile; a collaborative module estimates preference from interaction patterns. A hybrid ranker combines their scores, filters tracks already played too often, and optionally increases diversity across artists or genres. Recommendations are then displayed with simple explanations, such as “because you liked this artist” or “similar genre and tempo.”

Figure 1. Conceptual workflow: User Actions + Track Catalog → Data Validation → Feature Engineering → Content Similarity + Collaborative Model → Hybrid Ranking → Diversity / Repeat Filtering → Recommended Playlist → Feedback Loop

Allow users to browse the catalog and select preferred genres or artists.

• Generate a ranked list of tracks for a user profile.
• Record permitted interactions with timestamps and event types.
• Offer a fallback list when a user has no interaction history.
• Allow users to dismiss recommendations and revise preferences.
• Provide an administrative workflow to update metadata and monitor data quality.

Responsiveness: return recommendations within a practical response time for the prototype.

• Scalability: separate catalog, interaction, and ranking components.
• Reliability: handle missing metadata and empty profiles without failing.
• Privacy: collect only necessary data and support deletion of user history.
• Maintainability: version feature pipelines and recommendation models. 4. Methodology

The prototype can use an open music metadata dataset or a catalog created for testing. Interaction data may be generated through a small user study with consent, or sourced from an appropriately licensed dataset. Each record should have a stable track identifier. The project should document the dataset source, permitted use, collection period, and any transformation applied. Personal information is not required for the core recommender; pseudonymous user identifiers are sufficient for most experiments.

Remove duplicate tracks and resolve inconsistent artist or genre labels.

• Represent missing categorical metadata as unknown rather than silently inventing values.
• Convert interaction events into a consistent user–item matrix or event table.
• Distinguish explicit feedback (ratings or likes) from implicit feedback (plays or skips).
• Split evaluation data by time where possible to simulate future recommendations.

Each track is represented by a feature vector derived from available metadata. Categorical fields such as genre, artist, and language can be one-hot encoded or represented with suitable embeddings. Numerical fields such as tempo or release year can be scaled. A user profile can be formed from the weighted average of tracks the user likes, with negative feedback reducing the weight of similar items. Cosine similarity between the profile and candidate track vectors provides a straightforward baseline score. The content score may be expressed conceptually as: score_content(u, i) = cosine(user_profile_u, track_vector_i). This score is meaningful only when feature vectors are prepared consistently. Sensitive user attributes should not be inferred or used without a clear, justified purpose.

Collaborative filtering uses interaction patterns across users and tracks. For implicit feedback, a play or playlist addition can be treated as a positive signal, while a skip may be a weaker negative signal because users skip for many reasons. An item-item similarity baseline is easy to implement; matrix factorization can be explored if the dataset is sufficiently large. The training process must avoid using future interactions to predict earlier ones.

The hybrid ranker normalises component scores and combines them using weights selected on validation data. A conceptual formula is: hybrid_score(u, i) = α × content_score(u, i) + (1 − α) × collaborative_score(u, i), where α is tuned using validation results. When collaborative data are unavailable, the system can fall back to content similarity or popularity within the userselected genres. A diversity adjustment can penalise excessive repetition of the same artist or near-identical tracks.

For a new user, the interface can ask for a few favourite genres, artists, or languages and create an initial profile. For a new track, content metadata can provide a score even before interaction history accumulates. If both profile and metadata are missing, a transparent fallback such as recently added or broadly popular tracks can be used, with a clear indication that personalisation is limited.

Load the current user profile and eligible track catalog.

• Generate candidate tracks from content similarity and collaborative signals.
• Calculate and normalise available scores.
• Combine scores using validated weights and apply user exclusions.
• Adjust ranking for repetition and diversity constraints.
• Return top-K tracks with brief recommendation reasons.
• Record feedback only according to the stated privacy policy.

A practical implementation can separate the frontend, API, recommendation service, and database. The frontend collects preferences and displays ranked tracks. The API validates requests and checks the user session. The recommendation service loads a versioned feature pipeline and model, scores candidates, and returns track identifiers and explanation labels. The database stores catalog metadata and only the minimum interaction history needed for personalisation.

The database should use primary and foreign keys, validate event types, and index common lookup fields. Interaction history and recommendation logs should have retention policies. If user accounts are not necessary for the demonstration, local session identifiers can reduce the amount of personal data collected.

GET /tracks — retrieve catalog entries with pagination and filters.

• POST /preferences — save a user’s selected genres, artists, or languages.
• GET /recommendations?user_id=…&limit=10 — retrieve a ranked list.
• POST /feedback — submit a like, skip, save, or rating event.
• DELETE /profile/history — request deletion of stored interaction history.

Describe the dataset, number of users and tracks, event types, and time span.

• Define what counts as a relevant held-out interaction before testing.
• Use the same eligible catalog and test split for all compared models.
• Report metrics across users, including how users with little history are handled.
• Inspect errors and examples of repetitive or irrelevant recommendations.
• Record software versions, model settings, and random seeds for reproducibility. 6.2 Discussion A popularity baseline is easy to implement and useful for cold-start users, but it tends to over-recommend already popular tracks. Content-based filtering can surface new tracks with known metadata but may limit discovery. Collaborative filtering can learn broader taste patterns but requires sufficient interaction data and may struggle with new items. A hybrid model is expected to offer a practical balance, although this expectation must be tested rather than treated as a measured result. Results should also be interpreted in light of the dataset’s coverage and the definition of relevance. No numerical experimental results are included because this paper presents a proposed design rather than a completed benchmark. Once implemented, the system should report the actual test-set metrics and clearly distinguish measured findings from design expectations. 7. Advantages
• Personalises track suggestions using more than one information source.
• Can recommend new tracks using content features before interaction data exist.
• Supports user feedback to improve future rankings.
• Can balance relevance with diversity and catalog coverage.
• Uses modular components that can be evaluated and replaced independently.

Cold-start users may receive generic suggestions until preferences are collected.

• Sparse or biased interaction data can reduce collaborative model quality.
• Popularity bias may make lesser-known artists difficult to discover.
• User preferences change with mood, activity, season, and context.
• Metadata may be incomplete, inconsistent, or unavailable for some tracks.
• Offline metrics do not fully capture satisfaction, listening duration, or perceived novelty.
• Third-party catalog or streaming APIs may impose access limits and licensing restrictions.

Listening histories can reveal patterns about a person’s routines and interests. The system should explain what data it collects, why it is collected, and how it affects recommendations. Only the data needed for the feature should be retained; users should be able to clear their history or reset preferences. Identifiers should be pseudonymous where possible, and access to interaction records should be restricted. Recommendation algorithms can unintentionally narrow exposure by repeatedly promoting familiar content. The design can mitigate this by including diversity controls, allowing users to adjust preferences, and making it possible to explore unfamiliar artists. The system should avoid making sensitive inferences about a listener and should not imply that a recommendation is objectively best for the user.

Future work could evaluate audio embeddings, transformer-based representations, context-aware recommendations, multilingual metadata, and session-based models that respond to short-term listening patterns. A user study could compare satisfaction and perceived diversity between the hybrid system and a baseline. Online experimentation should only be conducted with informed consent and safeguards. Additional work may explore federated or privacy-preserving learning, fairness metrics for artist exposure, and model-drift monitoring as catalog trends change. 11. Conclusion This paper proposed a hybrid Music Recommendation System combining content-based filtering and collaborative signals. The design covers user and catalog data, feature preprocessing, candidate generation, ranking, cold-start fallback, feedback capture, and evaluation. It emphasises top-K relevance metrics alongside diversity, novelty, coverage, and privacy. The system provides a foundation for a student project, but the expected benefits must be confirmed through reproducible experiments and user-centred evaluation. A careful implementation should make recommendations understandable, protect listening history, and retain user control over preferences.