Я обычно подобные поделки не обсуждаю, но тут решил высказаться.
1. К "я бы пересмотрел необходимость иметь кучу справочников" +500. На битрейт и год справочник уж точно не надо. На кодек - возможно надо, только если от кодека что-то получить хочется. В 99,99% случаев достаточно просто поля, куда пихать значения типа flac, ape и т.п.
2. Фото из справочника артистов вообще убрать. Если уж хочется фото, это надо делать отдельной табличкой.

Вообще, надо приучаться к модульности и отсутствию излишней связанности при проектировании БД. Большая проблема очень многих людей в том, что они не видят, к чему приведет минимальное возможное изменение техзадания на БД. А оно не должно приводить к тому, что придется всё переделывать. Если это не просто диплом типа "сдал-забыл", тем более. При промышленной эксплуатации систем легкость поддержки и развития становится вообще краеугольным камнем и дамокловым мечом (в зависимости от радиуса кривизны рук). Поэтому в вашем варианте:
1. Как только появится необходимость прицепить 2-е фото музыканта, придется думать.
2. Как только придется необходимость прицепить скан диска, придется думать.
3. После 1 и 2 придется думать, почему фото музыканта и фото диска лежат в разных табличках, тогда как обе сущности суть фото, и вообще на обложке диска может быть изображен сам музыкант в виде вполне себе приличного фото.
4. Дополнительно. Насчет кодека - даже если потом потребуется сделать отдельный справочник кодеков и на него навесить какую-то логику, это всегоа можно будет легко сделать минимальным движением серого вещества: само же уникальное имя кодека, которое будет использоваться в варианте без справочника, будет уникальным кодом (или даже PK, кому как нравится) в справочнике.

boottyкогда перед этим во всех файлах кто-то тщательно ручками прописал и перепроверил все тэги. Иначе в базе будут исполнители "The Beatles", "Beatles", "Beatles, the" и т.п. (названия песен и альбомов, стилей - аналогично, даже при использовании CDDB)
Вообще-то это ETL пишется от структуры БД, а никак не наоброт. Вы ж наверное не предлагаете к каждой сущности навесить еще таблички с "синонимами"?

boottyНо если бы писал для онлайн-сервиса, то постарался бы предусмотреть такую возможность для основных сущностей.
Это настройка ETL (в Вашем применении БД), поэтому к самим данным непосредственного отношения не имеет. Это примерно как обосновать кроме необходимости внесения в синонимы "Beatles" еще и "Битлы", "Жуки", "Bitlz" и т.п. В общем, это примерно как желание увековечить ошибки, вместо желания их исправить. В инете достаточно утилит, чтобы пройтись по папкам и поправить теги mp3 как надо.