Not sure if it's already possible, there was nothing along those lines on the Wiki. Is there a way to generate asound ID for a music disc, and then assign it to a selection of multiple sounds using a resourcepack sounds.json? If not, it would be a nice addition.

There are 2 possibilities I can imagine:

1. The music disc is generated from the OGG file; the correlation is hardcoded. This would mean it's currently not possible. In this case, I'd like it to be changed such that there's resourcepack support.
2. The OGG file is used to generate both the music disc item, and a sound ID entry in the mod's generated sounds.json; the music disc item then uses that sound ID. In this case, one could do the above by adding the first file through the mod's usual process, and the remaining OGG files for the same music disc through a resourcepack with a sounds.json. Nothing to be done in this case, except documenting it.

There's some more stuff I didn't find any info on. These can be figured out by in-game means with commands, so they're not high priority, but not having every resourcepack/datapack author manually take apart your generated content would be preferable. These are:

• Names of generated item textures. I assume they're the same as the item names, which in turn are the same as the OGG file names, but both correlations are just assumptions.
• Recipe IDs for the Music Generator and Blank Music Discs, in case a datapack creator wants to disable them. This would be useful because in exploration-based environments, music discs are often seen as trophies and the current system defeats that purpose to some extent - it's perfectly fine for different approaches though, so I suggest documenting the datapack-based configuration options rather than removing the recipes altogether.

If i understand you correctly, you need to regiser multiple sounds with same name? If it is, this is impossible. Every sound should have a single name. I wonder for what pupose you need this?

There are option in config that disable all mod items but sounds. I'll add add new option that allow only music discs, thanks for the tip.

The way I understand it, it generates a sounds.json somewhat like this (if e.g. customrecord1.ogg and customrecord2.ogg are present):

{
    "record.mcdj.customrecord1": {
        "category": "record",
        "sounds": [
            "mcdj:records/customrecord1.ogg"
        ]
    },
    "record.mcdj.customrecord2": {
        "category": "record",
        "sounds": [
            "mcdj:records/customrecord2.ogg"
        ]
    }
}

And copies customrecord1.ogg and customrecord2.ogg into the generated resource pack as well. So it should be possible to e.g. have the customrecord1 music disc item randomize from customrecord1.ogg, extrasound1.ogg and extrasound2.ogg, while also having customrecord2 randomize from menu1, menu2 and menu3 by putting a resources.zip with this sounds.json in your world folder:

{
    "record.mcdj.customrecord1": {
        "replace": false,
        "category": "record",
        "sounds": [
            "mcdj:records/extrasound1.ogg",
            "mcdj:records/extrasound2.ogg"
        ]
    },
    "record.mcdj.customrecord2": {
        "replace": true,
        "category": "record",
        "sounds": [
            "minecraft:music/menu/menu1.ogg",
            "minecraft:music/menu/menu2.ogg",
            "minecraft:music/menu/menu3.ogg"
        ]
    }
}

Right now, however, the sound IDs (record.mcdj.customrecord1 and record.mcdj.customrecord2) are pure guesses, and I'd have to use in-game commands first in order to figure out the real sound IDs. Assuming it works by generating a resource pack - if it doesn't, then the design choice to do it differently is questionable at best.

Same goes for the item IDs that are generated. If I wanted to put the customrecord1 music disc into a loot table, then I'd first have to find out in game what the item ID is. Also, the recipes can be disabled by unpacking the JAR and looking at the names of the recipe JSON files, then replacing them (through a datapack) with an impossible recipe (e.g. one that uses Barriers), so it's already possible. Actually, on a second thought, forget the last bullet point of the description - what I've been asking for is spoon-feeding datapack creators your mod's datapack structure, which is a bad idea in hindsight.