Well if you have for example 8 animation sets each using 32 indicidual images, you could store all the images for one animation in a single larger file. This might be a bit quicker when running the animation since less SetTexture calls will be made, but you'd have to decide if you were happy using larger textures.

One question is why you use .dds files - since .bmp is the simpleset file fomat you'd imagine it would be fastest to load. .jpg is pretty complex so maybe takes longer to 'decode' to a surface. I don't know the .dds format and anyway I think it can vary depending on if you use compressed textures or whatever. .DDS also may be storing a mip-map chain for each texture which you may not want?

But are you SURE it's the texture loading? Can you tell us how many images you have to load (and the dimensions+image format) and how long it takes just to load the images (throw in a GetTickCount() or whatever before and after loading)?

Texture loading a lot of animation frames can definitely be slow. I combined my 16/32/64 frame animations into large single textures, and now I get faster rendering AND much faster loading.

With DDS, if you want mips, pre generate them and store them in the DDS. If you don't want mips, ensure you specify miplevels=1 when loading. If not, D3DX will decompress you DDS, shrink it, and compress each needed level. It takes a long time.

Other than that, you make a simple file format when you just append on each texture's name, size, and DDS file.

char texturename[32]
ulong texturefilesize
texturedata

Load the whole sucker into memory. Loop through each texture and use D3DXCreateTextureFromFileInMemoryEx(). The file overhead shouldn't be much of a problem. I'd suggest looking into the mip issues I mentioned above first.