自定义画和唱片需要两个包，而安装其中一个正是常见的失败原因
数据包负责注册内容；资源包提供纹理和声音。只装数据包，内容虽然注册成功却没有任何可显示的东西。另外还有 16×16 的限制，以及唱片长度真正控制的是什么，数据包和资源包各有一份 pack.mcmeta，是彼此独立的两个包。
画和音乐唱片在现代 Java 版中都是真正的注册表条目，这意味着你可以添加它们，而不是替换原版内容。你添加的任何东西都不会顶掉已有的画或唱片。
问题在于，内容被拆分在两种不同的包类型中，而单独任何一个都毫无用处。
什么放在哪里
数据包负责注册内容：
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_output资源包提供你看到和听到的东西：
assets/<ns>/textures/painting/<id>.png
assets/<ns>/sounds/<id>.ogg
assets/<ns>/sounds.json只安装数据包的话，内容会成功注册——它确实存在，/give 也能找到它，只是既没有纹理也没有音频。这种结果比直接报错要令人困惑得多，也正是自定义画“没生效”的常见原因。本页的工具特意把两者打包在同一个 zip 里，就是为了防止它们被分开。
注意那两个 pack.mcmeta 文件。它们是各自独立的包，拥有各自独立的身份；不存在能同时容纳两者的合并格式。
注册表 id 比文件名更严格
id 只能包含 a-z、0-9、_、. 和 -（子文件夹另加 /）。出现其他任何字符，游戏就会跳过该文件，并在日志中留下一行“Invalid path”——包能加载，但那个条目根本不存在，这比直接失败更难察觉。大写字母和空格是最容易让人中招的两个，因为在你拖进来的文件名里，这两者都再普通不过。
画：最大 16×16，17 会让整个包失效
原版自带的画从 1 × 1 到 4 × 4 方块不等，本工具也提供同样的范围。格式本身允许更大：26.3 会把 width 和 height 解读为 1 到 16 的整数方块，而一幅 16 × 16 的画只要有 16 × 16 方块的空间，就能在任何墙面上加载、悬挂并保持——已在 26.3 服务器上测试过。决定一幅画能否挂住的是空间，而不是尺寸：挂的位置放不下就会掉落成物品，原版 1 × 1 的画背后没有空间时同样会掉落。
超过 16 之后，游戏不会把数字截断，而是直接拒绝。"width": 17 会以“Value must be within range [1;16]”失败，整个注册表加载随之停止，在世界移除该包之前都无法打开。
尺寸在 JSON 中以 width 和 height 声明，单位为方块。它不会从 PNG 推断，所以一幅 3 × 1 的画即使纹理是正方形，也是合法文件，只是显示时会被拉伸。
唱片长度不是标签
length_in_seconds 是游戏判定曲目结束的时刻。在声明的长度之后一秒，唱片机会切断声音、停止音符，并关闭它在歌曲播放期间输出的红石信号——满强度，作用于周围的方块，持续时间正好等于它认为曲目还在播放的时间。
所以长度不准确不是外观上的小错。把一首 200 秒的曲目声明为 100 秒，音乐会在中途被切断，信号也在同一刻消失；声明为 300 秒，唱片机会在 100 秒的静默中一直保持信号。无论哪种情况，等待唱片结束的红石都会在错误的时刻触发。本工具正是出于这个原因，直接从文件中读取真实时长，而不是让你手动输入。
比较器读取的是另一回事：comparator_output，一个 0 到 15 的固定数值，只要唱片留在唱片机里就保持不变，无论正在播放还是已经结束。它不会随曲目推进而升高，长度也不会改变它——原版用它来区分唱片（13 为 1，cat 为 2，blocks 为 3）。
曲目还需要在 sounds.json 中写入 "stream": true。音乐很长，把整首曲目先加载进内存再播放会卡顿——对于唱片长度的内容，流式播放是正确的默认选择，而对于短音效则恰恰相反。