15,650 Uploads. Ten Tracks Are 82% of Everything. 9,859 Have Never Been Played.

I have 15,650 uploads across two SoundCloud handles and a YouTube channel. Together they hold 9,486,940 plays.

Two of those uploads are 51% of the plays. Ten are 82%. And 9,859 of them — 63% of everything I have ever put up — have never been played once.

I am publishing all of it, including the parts that make me look bad, because I could not find this study anywhere else. Plenty of people will tell you what a music catalog does. Almost nobody publishes the row-level distribution of their own, with the zeroes left in. The zeroes are the whole point. Any artist can screenshot a hit. The denominator is the part that costs something to show.

Everything below is recomputed from a file you can download.

The dataset, named exactly

The numbers in this article come from catalog.json — the same file this site serves to your browser, 17,005,000 bytes, last written 2026-07-30 at 06:00. I chose that file deliberately over the working copy on my own machine, for one reason: it is the only one you can fetch and check. A statistic nobody can recompute is a press release.

Each row carries a title, a stream_counts object keyed by source, and where available a SoundCloud track ID. "Plays" throughout means the sum of the numeric values in stream_counts for that row. Nothing is weighted, estimated, or modelled.

The three sources break down like this:

These are two separate accounts with two separate sets of uploads, so they are summed, not maxed. That distinction matters and it is the kind of thing that quietly inflates a headline number when nobody checks it.

Two rows are half the catalog

Here is the head of the distribution.

The more useful way to read the same data is to ask how many rows it takes to reach a given share of the total:

Top 50 is 88.26%. Top 100 is 89.46%. Top 500 is 93.88%. Top 1,000 is 95.43%. The curve is essentially flat after the first few hundred rows — which is another way of saying that 14,000 of these uploads are, statistically, noise around zero.

The denominator nobody publishes

9,859 rows sum to zero plays. That is 63.00% of the catalog.

The obvious objection is that those are sync gaps — rows the harvester never filled in. They are not, and I can separate the two cases because the shape of the JSON preserves the difference:

9,149 of them were asked and answered zero. And 9,299 of the zero-play rows carry a real SoundCloud track ID, which means they exist as live objects on the platform. They are not phantoms in a spreadsheet. They are uploaded, public, findable songs that nobody has ever pressed play on.

Worth saying plainly: 710 rows are honestly unknown, and I am counting them in the 9,859 headline rather than quietly dropping them. If you prefer the strict figure, use 9,149 — 58.46% of the catalog, measured.

What the played half looks like

Restrict to the 5,791 rows with at least one play and the distribution is still brutal:

The median track that got played at all got 137 plays. The top track has 2,857,881. That is a spread of roughly 20,860× inside one artist's own catalog, by one artist, in one genre lane.

Counting the ceiling instead: 11 uploads are over 100,000 plays. 23 are over 10,000. 304 are over 1,000. 3,528 are over 100. The mean across all rows is 606 plays, which is a number that describes not one single track in the file — the classic failure of reporting an average over a power law.

The row I cannot fully verify, and what happens if it is wrong

Rank 1 has a defect and I am not going to bury it.

The record titled Call From Lester (made on bandlab Iphone app) carries 2,857,881 plays attributed to the supercooldaj handle, but the supercooldaj URL stored on that same row points at soundcloud.com/supercooldaj/double-back. "Double Back" is a different song — there are 35 rows matching that title elsewhere in this catalog, the best of them at 1,625 plays, and not one of them carries a supercooldaj play count or a supercooldaj URL. Separately, a second row with nearly the same Lester title exists on the other handle with 225 plays.

So one of two things is true: either that URL is a stale slug from a re-title, or the title-to-URL join on that row is wrong. The play count itself is attached to a single SoundCloud track ID, so the magnitude is a real count for a real track on that account — what is unresolved is which song's name belongs on it. Resolving it requires opening the URL and reading what is actually there, which I have not done at the time of writing.

That row is 30.12% of every headline number above, so here is the sensitivity analysis. Drop it entirely and recompute on the remaining 15,649 rows:

The finding survives its own worst case. Even with the single largest row deleted, ten uploads out of fifteen thousand still carry 78% of the plays, and the zero-play count does not move at all. That is what a robust result looks like, and I would rather show you the stress test than pretend the row is clean.

Three counts, one catalog

While assembling this I found something worse than a bad row, and it belongs in the article rather than in a private ticket.

There are three live numbers for how many tracks I have, and they disagree:

The first two were written by the same job, at the same minute, and differ by 245 rows. I diffed them: the served file is a strict superset. All 245 extra rows carry real SoundCloud track IDs, together holding 49,616 plays, and not one of their 141 distinct titles appears anywhere in the working copy. Six further rows present in both files carry different play counts in each. The file named "full" is the smaller one.

The third number is a hand-maintained constant that has drifted below both.

I am not going to publish a study whose denominator is in dispute without saying so, so: this article uses the served file, because that is the artifact a reader can fetch. The working copy gives 15,405 rows, 9,437,281 plays, top-10 at 82.86%, 9,834 zero-play rows and a median played track of 136. Every conclusion in this article holds on both files to within a few tenths of a percent. That is reassuring about the finding and damning about the pipeline, and both of those are true at once.

What bulk uploading actually returned

The most direct test of "does uploading more work" is sitting in the project field, because two of the groupings are literal bulk re-uploads of master files.

Those two groups are 58.5% of the entire catalog and produced 1.36% of the plays. Both figures are identical in both data files, so this one is not affected by the reconciliation problem above.

I want to be careful about what this does and does not show. It is confounded by recency — these were uploaded in bulk in 2026 and have had less time to accumulate — and by selection, since a bulk master dump is not a release campaign. It is not evidence that the songs are bad. It is evidence that the act of uploading, by itself, buys approximately fourteen plays. Distribution is not promotion. I paid for that lesson nine thousand times.

One thing I deliberately left out: I had planned to compare the "Freestyle" grouping against the bulk masters, and the per-track gap there looked enormous. Then I checked both files and found the project labels on the high-play rows disagree between them — the working copy assigns them, the served copy leaves them null. So that comparison is not currently computable to a standard I would publish. It is in the reconciliation queue with the rest.

My ear, graded against the data

There is one hand-curated playlist in the file: GODS TIER 2026 — DAJ' Greatest Hits. I built it by ear, picking what I thought were the best things I had made. It holds exactly 24 tracks.

Those 24 tracks hold 8,231,272 plays — 86.76% of the catalog's lifetime total.

I did not build that list by looking at play counts. I take a specific kind of comfort in that: taste and the distribution agreed, after the fact, at 24 picks out of 15,650. It is a sample of one artist and I would not generalise it into a law. But if you have ever wondered whether your own sense of which of your songs are the good ones is worth anything — mine was, and this is the receipt.

What 15,650 files cost

3,735 of the rows carry a duration. That is a subset, not the catalog, and I am saying so out loud rather than multiplying a median by 15,650 and printing a fake number.

Across those 3,735: 189.33 hours of audio — 7.89 days of continuous runtime. The median track is 173 seconds, two minutes fifty-three. Extrapolating to the full file would give something over three weeks, and I am not going to print that as a fact because the sampled rows are not a random sample.

The dates in this file are not release dates

13,441 rows carry a release_date, and 13,340 of those are stamped 2026. That is not a discography. Those are upload timestamps from the bulk re-upload runs, and rendering them as a release history would be the single easiest way to turn this dataset into a lie. Anywhere you see this catalog visualised over time, that is what those dates mean.

Related, and covered properly elsewhere: isrc is null on all 15,650 rows. 101 rows have an Apple Music URL, 10 have Spotify, 631 have YouTube. The compositions side of my metadata is in far better shape than the recordings side, which is its own article.

A correction to something I published three weeks ago

On 2026-07-10 I published 14,000 Tracks Deep: Why Catalog Volume Is the Independent Artist's Real Moat. It argued that catalog volume is itself the moat — that every track is a door, and fourteen thousand doors beat ten.

The row-level data does not support the strong version of that claim, and I am not leaving it standing unchallenged. 9,859 of those doors have never opened. Two of them are half the building.

What survives from the older piece is real and I still believe it: volume is how you get reps, reps are how you get better, and I could not have predicted which ten tracks would land. The part that does not survive is the implied causation — that uploading more creates the tail. It does not. The tail is 63% zeroes. A catalog is a distribution, not an inventory, and the distribution is decided almost entirely by the top of it.

I have added a note to the older post pointing here. Two contradicting theses sitting on one domain is exactly the kind of thing that should cost a site its credibility, so I would rather correct it in public and date the correction.

What I would actually tell another independent artist

Not "stop uploading." The reps are real and I have the catalog to prove I did them.

What the data says is narrower and more useful: uploading is not distribution, and distribution is not promotion. The 9,150 bulk-uploaded masters earned 14 plays each because uploading is the only thing that happened to them. The tracks at the top of this table had something else happen — a feature, a moment, a video, a co-sign, a platform surfacing them.

So: keep making. But stop counting uploads as progress, and start counting the ones you actually did something for. On my own numbers, those are two completely different catalogs sharing a folder.

If you want the polished end of this, 36 of these tracks went through my own mastering engine this month and I published the measured outcomes — including a defect it shipped — on the mastering page. The top 50 is the concentrated head of the curve above. The discography is the part that made it to stores, and DARK I is the one I would start with.

How to check any of this yourself

Fetch catalog.json from this domain, then sum the numeric values of each row's stream_counts object. Sort descending. Every table above falls out of that one operation — the shares, the percentiles, the zero counts, the sensitivity analysis. There is no intermediate model and no private step.

If you get a different answer than I did, the file moved, and I would rather hear about it than not. Snapshot date on everything here: 2026-07-30.

FAQ

How many of Daj's tracks have never been played?

9,859 of 15,650 uploads — 63.00% — have zero recorded plays as of 2026-07-30. Of those, 9,149 returned an explicit zero from the platform API, and 710 were never successfully fetched and are honestly unknown.

What share of a large independent catalog do the top tracks hold?

In this catalog, 2 uploads hold 51.25% of all plays, 10 hold 82.43%, and 131 hold 90%. The remaining 15,519 uploads share under 10% between them. This is one artist's catalog measured directly, not an industry average.

How many plays does a typical track get?

Across the 5,791 uploads with at least one play, the median is 137 plays and the 25th percentile is 17. Across all 15,650 rows the mean is 606, which describes no actual track in the file — reporting a mean over a power-law distribution is misleading by construction.

Does uploading more music increase plays?

Not on its own. Two bulk re-upload groups in this catalog account for 9,150 uploads — 58.5% of everything — and produced 128,657 plays between them, about 14 plays per upload and 1.36% of the lifetime total. The observation is confounded by upload recency, so treat it as a strong hint rather than a controlled result.

Why does this site report three different track counts?

Because it currently has a data-integrity bug, disclosed here rather than hidden: the served catalog file holds 15,650 rows, an internal working copy from the same sync run holds 15,405, and a hand-maintained constant says 14,030. The served file is a strict superset of the working copy by 245 rows. This article uses the served file because it is the one a reader can independently fetch. Reconciliation is open work.