Your current structure will have the same data over and over - this is a waste and if you want quicker queries, you would be better off to store those in different tables. Example: 1 artist, three albums, 12 tracks per album, this means you'll be storing the artist name 36 times, the album names 12 times each.

Here's a better start that moves toward normalization:

artists
id ¦ artist_id ¦ artist_title ¦ other_data ¦comments

albums
id ¦ artist_id ¦ album_id ¦ release_date ¦ formats ¦ comments

tracks
id ¦ album_id ¦length ¦ comments

Your select statements become a little more complex, requiring joins, but your database is smaller and normalized, and you have a more robust basis for various types of searches.

There are a couple important points here, one you'll probably spot right off, the other, maybe not.

Note for each table I have "id," an auto-increment field, and a unique identifier field (artist_id, example.) Many programmers use the id field to do their joins - including myself, . . .sometimes . . . but it's not the best idea. If the data needs to be re-imported, those auto increment fields may change. A unique id you generate will not.

A positive aspect of normalizing your tables is it allows you to do searches on integer fields, which are always faster than searching text fields:

select * from tracks where album_id=12345;

Well I understand what your saying about speed and such but due the fact I am not that advanced with mysql and php I think I would like to stick with what I have.

What I want to happen is for every filled out "track" input I want a line posted into a mysql table with the artists name, track name, and album name.