data fields while ripping

[shoskey]

So this gets complicated but i will try... I work for a Public tv/radio station and we want to archive our entire music library, over 120,000 songs. I have been working on this project for years and we are almost ready to start. This is one of my final problems.... We are going to use dbpoweramp to rip all of the CDs aprx 13,000 in basically 3 formats... classical, jazz, and folk. We are using Wave (we want uncompressed) and i need to in turn make a searchable database.. i was planning on using excel. when i Rip a disk and lets say it has a composer field I then take the ripped music run it through batch converter to strip the audio information off into a text file then import into excel all is good... until i rip a disk with NO composer field then all of my columns are off due to the fact there is no composer field... this is not a problem to fix if we did not have such a large library....

so my question is... can the program "add" blank fields or can I "lock down" a set of fields so even if there is NO information it will just be blank??? or am i missing something? any better way of doing it..

HELP!!! I really want to preserve this library we estimate it to take about 5 years I want to do it right....

thanks,
shawn

[garym]

Re: data fields while ripping

So this gets complicated but i will try... I work for a Public tv/radio station and we want to archive our entire music library, over 120,000 songs. I have been working on this project for years and we are almost ready to start. This is one of my final problems.... We are going to use dbpoweramp to rip all of the CDs aprx 13,000 in basically 3 formats... classical, jazz, and folk. We are using Wave (we want uncompressed) and i need to in turn make a searchable database.. i was planning on using excel. when i Rip a disk and lets say it has a composer field I then take the ripped music run it through batch converter to strip the audio information off into a text file then import into excel all is good... until i rip a disk with NO composer field then all of my columns are off due to the fact there is no composer field... this is not a problem to fix if we did not have such a large library....

so my question is... can the program "add" blank fields or can I "lock down" a set of fields so even if there is NO information it will just be blank??? or am i missing something? any better way of doing it..

HELP!!! I really want to preserve this library we estimate it to take about 5 years I want to do it right....

thanks,
shawn

Sorry, but you're approaching this project using so many bad choices and manual approaches that I don't even know where to begin. You say you want uncompressed. Do you understand the difference between Lossless and Lossy? FLAC is lossless (bit perfect) but has many, many advantages over a WAV file (including better tagging, self-contained CRC for batch checking for corruption later on, not to mention smaller size). And there are lots of ways to create a searchable database of your music without copying it into EXCEL. Heck, I can create a searchable EXCEL of my ~100,000 track library with a few mouse clicks in a batch manner (because I have good tagging).

Don't take my thoughts the wrong way. Folks here can help, but if you've been researching this for years, you've been looking at the wrong spots.

[Dat Ei]

Re: data fields while ripping

I agree with Gary. And aside from this: excel isn't a database at all. Once I told a customer, who loved to solve every problem with excel, that excel is from unstructured people for unstructured people.


Dat Ei

[schmidj]

Re: data fields while ripping

Gary, he has one issue that may force him to .wav files. At least some of the radio broadcast automation systems only play .wav files, or mp3 and wav, or something like mp2 and wav. The system at the radio station I'm Chief Engineer of is like that, it won't deal with FLAC or even m4a. and it is one of the most common systems. In fact we used the same system at ABC TV before I retired. I've talked to them about adding codecs, and gotten nowhere. Stations choose automation systems because of their ability to play according to schedule and the user interface, not because of the file formats they do or don't support. So it is likely he is stuck with .wav. Yes, he could rip to FLAC and then convert to .wav, but that is double work. Also, most of these systems don't use tags, they use serial number file names and have a database that is separate with the metadata (and a lot of metadata needed for smooth automation, like kill dates, segue times, etc.) A lot of the files aren't music, they are commercials, newscasts, station IDs , etc. Most of those systems allow bulk entry to the database via Excel, hence his spreadsheet. The base software for these automation systems long predates FLAC or metadata stored in files. Its a whole different world from home music playback.

I am not sure if this is what drives the direction he is going, but I wouldn't be surprised. If he is using one of these automation systems, he even has to make sure it will play a .wav file with embedded metadata cleanly, that it doesn't think the metadata is part of the audio and output a burst of noise.

[garym]

Re: data fields while ripping

Gary, he has one issue that may force him to .wav files. At least some of the radio broadcast automation systems only play .wav files, or mp3 and wav, or something like mp2 and wav. The system at the radio station I'm Chief Engineer of is like that, it won't deal with FLAC or even m4a. and it is one of the most common systems. In fact we used the same system at ABC TV before I retired. I've talked to them about adding codecs, and gotten nowhere. Stations choose automation systems because of their ability to play according to schedule and the user interface, not because of the file formats they do or don't support. So it is likely he is stuck with .wav. Yes, he could rip to FLAC and then convert to .wav, but that is double work. Also, most of these systems don't use tags, they use serial number file names and have a database that is separate with the metadata (and a lot of metadata needed for smooth automation, like kill dates, segue times, etc.) A lot of the files aren't music, they are commercials, newscasts, station IDs , etc. Most of those systems allow bulk entry to the database via Excel, hence his spreadsheet. The base software for these automation systems long predates FLAC or metadata stored in files. Its a whole different world from home music playback.

I am not sure if this is what drives the direction he is going, but I wouldn't be surprised. If he is using one of these automation systems, he even has to make sure it will play a .wav file with embedded metadata cleanly, that it doesn't think the metadata is part of the audio and output a burst of noise.

Good point. I was a guest DJ on a station a while back (just for fun) and I recall that I had to provide my music to the station in WAV. If he's forced to use a spreadsheet with constant columns, he likely needs to make sure that every tag field is filled upon ripping, even if using "NA" or "Various". Seems like a database program containing the metadata that can then produce an excel file might be a better option. If he has excel, he probably has something like ACCESS.

[Spoon]

Re: data fields while ripping

If you really wanted Excel, then you could load Asset UPnP on your system and have it scan the wave files. There is a dumping program with Asset which can dump to excel, however you are better browsing Assets SQLLite database.

[shoskey]

Re: data fields while ripping

Good point. I was a guest DJ on a station a while back (just for fun) and I recall that I had to provide my music to the station in WAV. If he's forced to use a spreadsheet with constant columns, he likely needs to make sure that every tag field is filled upon ripping, even if using "NA" or "Various". Seems like a database program containing the metadata that can then produce an excel file might be a better option. If he has excel, he probably has something like ACCESS.

This is indeed the case we have a on air automation system that i am tied to... it does not support FLAC.
I am not in love with excel truth is i really do not like it at all. The problem I am facing is... I need to have a large library that must be .wav and each file needs to have a individual ID number. SO we have figured out a numbering system that will work and is something we can work with while still using it on the air during the transition. We still play vinyl everyday. (that is the next step we have over 13,000 records to digitize also... about 27,000 total albums (record and CD). So you can imagine that i do not want to get to the end and only have album, song title, and a number. The excel is more to retain more information that i hope to integrate with a better program in the future. (for example music master) in the past they used proprietary databases that went out of business and we almost lost all the data. (this is why the old database is not reliable) My thinking is that "Excel" information is future proof... but definitely not very useful to search
. I am welcome to any and all advice I by all means am not an expert... truth is i am and Television operations person.. I am taking on the radio archive project on the side because I would hate to see a 50 year library disappear due to fire or something like that... I have VERY SMALL budget to work with, but we are a college so i have student workers who can churn away ripping music all week...

[shoskey]

Re: data fields while ripping

If you really wanted Excel, then you could load Asset UPnP on your system and have it scan the wave files. There is a dumping program with Asset which can dump to excel, however you are better browsing Assets SQLLite database.

Is that the one you use with batch converter... that is what I am working with the problem is as fields change so do the columns and if you import disks with different fields the spacing is off. That is why i was wondering if i can "lock down" columns so that if the amount of data changes between disks it will not throw off the columns.

[Spoon]

Re: data fields while ripping

Asset is a separate program, it is a UPnP server, however it has a good internal database.

[shoskey]

Re: data fields while ripping

thanks... any chance of a setting i am missing that would put a blank comma space for a fixed number of data points?

[shoskey]

Re: data fields while ripping

Thank you for your insights.. Database aside...
My real issue is the changing Data fields. is there a way to lock in fields permanently? For example let's say the UPC field is there a way for me to have it always a visible data field instead of having to add it every time i rip a disk.. It seems minor but I would like to have other fields like this also and over 1000's of CDs it would save a lot of time....

[Spoon]

Re: data fields while ripping

Yes CD Ripper Options >> Meta Data & ID Tags >> Add a custom tag, add your upc tag set to 0000 or <edit me>

[shoskey]

Re: data fields while ripping

Yes CD Ripper Options >> Meta Data & ID Tags >> Add a custom tag, add your upc tag set to 0000 or <edit me>

does the < edit me> change if there is metadata to auto fill the space? or does that "lock out" the field? Or better question is there a <> command that is just a placeholder until there is data mined from the internet search and then it is replaced
?

[Spoon]

Re: data fields while ripping

This fixed tag value would overwrite any UPC from the Internet.