Custom paintings and discs need two packs, and installing one of them is the usual failure
The datapack registers the content; the resource pack supplies the texture and the sound. Datapack alone and it registers with nothing to show. Plus the 16×16 limit and what disc length really controls.
Paintings and music discs are both real registries in modern Java, which means you can add them rather than replace vanilla ones. Nothing you add displaces an existing painting or disc.
The catch is that the content is split across two different pack types, and each is useless alone.
What goes where
The datapack registers the thing:
data/<ns>/painting_variant/<id>.json asset_id, width, height, title, author
data/<ns>/jukebox_song/<id>.json sound_event, description, length_in_seconds, comparator_outputThe resource pack supplies what you see and hear:
assets/<ns>/textures/painting/<id>.png
assets/<ns>/sounds/<id>.ogg
assets/<ns>/sounds.jsonInstall only the datapack and the content registers successfully — it exists, /give finds it, and there is simply no texture and no audio. That is a much more confusing outcome than an outright failure, and it is the usual reason a custom painting "didn't work". The tool on this page ships both in one zip specifically so they cannot be separated.
Note the two pack.mcmeta files. They are separate packs with separate identities; there is no combined format that holds both.
Registry ids are stricter than filenames
An id may contain only a-z, 0-9, _, . and - (plus / for subfolders). Anything else and the game skips that file with an "Invalid path" line in the log — the pack loads, and the entry simply never exists, which is harder to spot than a failure. Capital letters and spaces are the two that catch people, because both are perfectly ordinary in the filename you dragged in.
Paintings: up to 16×16, and 17 breaks the pack
Vanilla's own paintings run from 1 × 1 to 4 × 4 blocks, and this tool offers the same range. The format allows more: 26.3 reads width and height as whole blocks from 1 to 16, and a 16 × 16 painting loads, hangs and stays up on any wall with 16 × 16 blocks of room — tested on a 26.3 server. What decides whether a painting stays up is room, not size: one that does not fit where it hangs drops as an item, and a vanilla 1 × 1 with nothing behind it drops just the same.
Past 16 the game does not clamp the number, it refuses it. "width": 17 fails with "Value must be within range [1;16]", the whole registry load stops with it, and the world will not open until the pack is removed.
The size is declared in the JSON as width and height, in blocks. It is not inferred from the PNG, so a 3 × 1 painting whose texture is square is a valid file that displays stretched.
Disc length is not a label
length_in_seconds is when the game decides the track is over. One second after the declared length the jukebox cuts the sound, stops the music notes, and switches off the redstone signal it gives out while a song plays — full strength, to the blocks around it, for exactly as long as it thinks the track is still going.
So an inaccurate length is not a cosmetic error. Declare a 200-second track as 100 and the music is cut off halfway, with the signal dropping at the same moment; declare it as 300 and the jukebox keeps its signal on through 100 seconds of silence. Either way, redstone waiting for a disc to end fires at the wrong time. This tool reads the real duration out of the file rather than asking you to type it, for exactly that reason.
A comparator reads something else: comparator_output, one fixed number from 0 to 15 that holds for as long as the disc sits in the jukebox, playing or finished. It does not rise across the track, and the length does not change it — vanilla uses it to tell discs apart (13 gives 1, cat 2, blocks 3).
Tracks are also written with "stream": true in sounds.json. Music is long, and loading a full track into memory before playing it stutters — streaming is the right default for anything disc-length, and the wrong one for a short sound effect.