Member Avatar for nhal

Hi
I have this application idea for a java program as my final year project and was wondering if it was feasible.
It invloves generating id tags for audio tracks. However instead of the data being based on existing data and filling in the missing info, The application will analayse the track, create a signature, which it will compare with other signatures stored in a database and retrive the corresponding track information.

Please advise on the possibilities of creating such an application.
Thanks in advance for any assistance

NHAL

  • 3 Contributors
  • 3 Replies
  • 113 Views
  • 16 Hours Discussion Span
  • Latest Post Latest Post by peter_budo

Dani AI

Generated

Feasible and well‑scoped as a final year project. As noted, Shazam‑style systems have been built before, but implementing a full pipeline, validating robustness, and solving scale or accuracy tradeoffs is still a solid engineering and research task. The core idea is to convert audio into a compact, noise‑resistant signature (a fingerprint) made from spectral peaks, then match those fingerprints against an indexed database (Audio fingerprint).

A minimal pipeline (conceptual) looks like:

load audio -> resample & mono -> compute STFT (e.g. 2048/4096 window, 512/1024 hop)
-> find local spectral peaks (constellation map)
-> create paired hashes (anchor freq, partner freq, delta time)
-> store hash -> (trackId, timeOffset)
Query: create hashes from sample -> lookup hash hits -> vote by (trackId, delta)
-> choose track with most consistent offset

Practical tips and libraries: use a Java audio library such as TarsosDSP for I/O, resampling and STFT. For production‑grade fingerprints consider Chromaprint/AcoustID (open source) and either call it from Java or integrate via a service (Chromaprint, AcoustID). For storage start with an inverted index (hash key -> list of (track,offset)); SQLite or PostgreSQL is fine for testing, while distributed key‑value stores or sharded indexes are needed at scale.

Common pitfalls: poor peak detection parameters (too many/too few peaks), mismatched sample rates, heavy compression or pitch/time shifts, and hash collisions. Visualization of spectrograms and peak maps helps debugging. As said, prior art doesn’t preclude originality — improvements in robustness, indexing, UI, or evaluation methodology make good project contributions.

Recommended Answers

All 3 Replies

Member Avatar for jwenting

certainly feasible. I did something somewhat similar a decade ago.

Member Avatar for nhal

OK
and here I thought I had an original idea. Maybe I should do some more thinking. :-)

Member Avatar for peter_budo

Do not worry it is original idea, that it was done decade ago doesn't mean can be done again.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.