How do I store a rating in a song? - c#

I want to be able to store information about a song that has been opened using my application. I would like for the user to be able to give the song a rating and this rating be loaded every time the users opens that file using my application.
I also need to know whether I should store the ratings in a database or an xml file.

C# ID3 Library is a .Net class library for editing id3 tags (v1-2.4). I would store the ratings directly into the comments section of the mp3 since id3v1 does not have many of the storage features that id3v2 does. If you want to store additional information for each mp3, what about placing a unique identifier on the mp3 and then having that do a database lookup?
I would be cautious about adding custom tags to mp3s as it is an easy way to ruin a large library. Also, I have gone down this road before and while I enjoyed the programming knowledge that came out of it, trying something like the iTunes SDK or Last FM might be a better route.

I would use a single-file, zero-config database. SQL Server Compact in your case.
I don't think XML is a good idea. XML shines in data interchange and storing very small amounts of information. In this case a user may rate thousands of tracks ( I have personally in online radios that allow ratings), and you may have lots of other information to store about the track.
Export and import using XML export procedures if you have to. Don't use it as your main datastore.

I would store it in a file as it is easier to keep with the mp3 file itself. If all you're doing is storing ratings, would you consider setting the ID3 rating field instead?

For this type of very simple storage I don't think it really matters all that much. The pro's of XML is its very easy to deploy and its editable outside of your app. the con's are, its editible outside your application (could be good, could be bad, depends on your situation)
Maybe another option (just because you can ;-) is an OODBMS, check out DB4Objects, its seriously addictive and very, very cool.

As mentioned earlier it is better to store such information in media file itself. And my suggestion is to use TagLib# lib for this (best media metadata lib I can find). Very powerful and easy to use.

I would store the ratings in a XML file, that way it's easy to edit from the outside, easy to read in .NET and you don't have to worry about shipping a database for something simple with you application.
Something like this might work for you:
<Songs>
<Song Title="{SongTitle}">
<Path>{Song path}</Path>
<Rating>3</Rating>
</Song>
</Songs>

If the song format supports suitable meta data (eg. MP3), then follow Kevin's advice of using the meta data. This is by far the best way of doing it, and it is what the meta data is intended for.
If not, then it really depends on your application. If you want to share the rating information - especially over a web service, then I would go for XML: it would be trivial to supply your XML listings as one big feed, for example.
XML (or most other text formats) also have the advantage that they can be easily edited by a human in a text editor.
The database would have its advantages if you had a more closed system, you wanted speed and fast indexing, and/or have other tables you might want to store as well (eg. data about albums and bands).

Related

What schema, database, searching libraries are good for storing thousands of book pages in c# app

I want to write a C# program to store some books with the total of 5000 pages. But there are a few important issues here that I need your help and advice:
The ability to search all of the books’ content is one of the most important and challenging features of the app. The time that is needed to search a word should be about the time required to search a word in Microsoft Word or a PDF doc (with the same size) or more.
What method should I employ for storing the books so that more suitable approaches to searching the content would be in hand? Relational DB, MongoDB, couchDB, etc. which one is preferred?
For the case of using Database, what kind of Schema and indexing is required and important?
Which method or algorithm or library is better to be used for searching the whole content of the books? Is it possible to use lucene or Solr in a standalone windows app or would traditional searching method be better?
The program should be customized in such a way that the publisher would be able to add their own book contents. How can I handle this feature (can I use XML)?
The users should be able to add one or more lines from the contents to their favorite list. What is the best way to deal with this?
I think Solr will be able to meet most of these requirements. For #1, you can easily develop schema in Solr to hold various information in different formats. Solr's Admin UI has an Analysis tab that will help you greatly in developing your schema because it allows you to test your changes on the fly with different types of data. It is a huge time saver because you don't have to create a bunch of test content and index it in to test it. Additionally, if the contents of the books are in binary format you can use Apache Tika to perform text extraction. Solr also has a number of other bells and whistles that you may find helpful, such as highlighting and user query spell suggestion.
For #2, Solr will support updates to content via JSON files that can be sent to the update handler for your collection. It also supports atomic updates which you may find useful. It seems that in your case, you may need some kind of a security solution to sit on top of Solr to prevent publishers from modifying each other's content, however you will most likely run into this issue regardless of the type of solution you will use.
For #3, I am not sure what you are really looking for here. I think that for content search and retrieval you will find Solr a good fit. For general user information storage and etc, you may need a different tool, since that is kind of outside of scope of what Solr is supposed to do.
Hope it helps.

How to properly save application data for later use

Ok, so I am working on a c# windows forms application and it uses different types of structures that hold data and display to the user. I want to use a saveDialogBox to allow the user to save the information(i.e configuration, state). The only way I can think to do this is to make a routine that goes through the structures and write the corresponding elements to a text file. Upon loading this routine would be used to load the data back.
This is of course a dumb way to do it I'll admit. Anything I've done in school was only writing to text files. Is there other ways to make some formatted file to save and load from?
I've been looking at serialization to save objects to files. I am not too sure how all this works though. help.
to save your application setting .. I think these links will help you
http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx
http://www.thescarms.com/dotnet/AppSettings.aspx
and
How to use settings in Visual C#
My 'Old School' way of doing this has always been to save settings during the program execution to a database (providing that you take the time to ensure you're not hammering the database with updates / inserts).
If my application needs to be more efficient AND I need to easily be able to recall the saved settings I serialize to XML using System.Xml.Serialization (from memory). XML serialization is human readable which is helpful (but not the most efficient in terms of processing time).
If I need even more efficiency you can go the whole way and serialize to binary.
I'd suggest reading / understanding http://msdn.microsoft.com/en-us/library/Vstudio/ms233843.aspx in it's entirety before coming back here. I'd say once you read this you'll be far better equipped to make a decision on which way you want to take your application.
In my experience there aren't that many DUMB ways to solve problems however there is almost always a better way to solve them given enough time and research.

Making data in an XML not able to be edited via a text editor

I'm currently following a tutorial series for a Tile Engine which uses XML files to store conversations between NPCs. A topic it doesn't appear to cover (I have only quickly glanced through the subsequent videos) is how to prevent the user from either altering or knowing in advance what the NPC is going to say by opening the XML file easily with a generic text editor.
The 2nd point of being able to read future conversations is not a real issue but something I wanted to think about, so if that's hard to implement I am not too fussed at this point.
How would I go about making the XML uneditable? I know vaguely about CRC32's which can check file integrity which may be useful and I also think there might be better ways to go about that (i.e. not with a CRC32).
The most extreme action I can think of would be to create my own arbitrary encoding for the conversation data, but the usefulness of XML files deters me from that slightly, and with the tutorials I'm following teaching me a lot things I don't know, I would prefer not to defer too far away from them!
Just looking for a direction really, thanks!
Xml is in its fundamentals an open format, so I mean there is not way how to make xml uneditable.
But you can have a copy of xml document (or some of fingerprint of xml) on your server (or on endpoints of NPC conversation) and then you can compare if xml document was edited or no.
If document was edited, you cas replace it with backup version or say to endpoints, that xml document was corrupted...
Historically, many games wrap multiple resources into a single binary file.
You might put it in a ZIP file (and maybe change the file extension). That would allow you to avoid having an XML file with an obvious name as a temptation for your users :).
Ultimately, you're asking something similar to the DRM question. I don't know whether your platform has an answer to that. (E.g., "using RSA encryption" is not secure as such; your program still has to decrypt the data at some point using the appropriate key, etc).

What is the best way to store area data for a text adventure?

I'm developing a "Zork" style text adventure in C#, and it's going to have a fairly large number of different areas with descriptions and environmental modifiers. I don't want to have a database, ideally, unless it really is the best way of doing it.
I need advice on the best way to store/load this data.
It will include:
Area description
Environmental modifiers (windows open/broken, door closed)
Items present by default
I would solve your problem by abandoning C# and writing your program in Inform7. Inform7 is just about the most awesome programming language I have ever seen and it is specifically designed to solve your problem.
The awesome thing about Inform7 is that you write your text adventure in a language that resembles text adventures. For example, here's a fragment of one of the sample adventures' source code:
The iron-barred gate is a door.
"An iron-barred gate leads [gate direction]."
It is north of the Drawbridge and south of the Entrance Hall.
It is closed and openable.
Before entering the castle, try entering the gate instead.
Before going inside in the Drawbridge, try going north instead.
Understand "door" as the gate.
This adds an object to the game - the object is a door, it is called "the iron-barred gate". A door is understood to be between two rooms, in this case, the drawbridge and the entrance hall. If the player tries to "enter the drawbridge" then the game logic will know that this is the same as "go north", and then the door logic will determine whether the door is closed or not. And so on. It makes writing text adventures extremely easy.
Is there some particular reason why you want to use C# instead of a domain-specific language like Inform7? If your goal is to learn how to write C# code or how to build a parser or whatever, then by all means do it yourself. If your goal is to write a text adventure, then I'd use a language designed for that.
Serialize all the data to file. It will ensure the smallest footprint when the user installs the game, without any real disadvantage. A database is great when you have a lot of data, but you are talking about a text adventure in which you will load the entire game contents into memory. A simple file will work for this very nicely.
Note, I'm not talking about xml but binary serialization. Any kind of text serialization will allow users to peek at your data, and either cheat or hack up the game. And you can just as easily swap in/out the serialized data file whether it's text or binary. Remember, your whole 'text' is likely to be just a few hundred kilobytes at most.
There are many interactive fiction engines already. I would take a look at their data formats, that way you can re-use existing content and tools for editing the content.
The most popular engines currently are Glulx http://eblong.com/zarf/glulx/ and Z-Machine http://en.wikipedia.org/wiki/Z-machine
Here is a technical reference for the Glulx format: http://eblong.com/zarf/glulx/technical.txt
I know you didn't want a DB, but have you looked at SQL Server Compact Edition? It might just do what you want.
I'd argue C# offers you precisely the right tools for this. Just encapsulate your structures into classes. Our first OOP project at university was exactly this problem! It is the perfect case study for OOP.
You can then use C#'s many serialization methods to store it persistently (load/save) however you see fit.
How would 'scripting' your adventure as one large text file sound? Then have your application parse this file, build the adventure in classes and run from there?
This would mean you could edit the adventure using a simple text editor. I would imagine that when multiple decisions can be made from a single source it may become tricky visualising the links. However this would also be tricky in a DB without some specialist front-end.
UPDATE:
Or have you considered XML eg...
<area id="DarkRoom1">
<description>Dark Room</description>
<item>Bucket</item>
<item>Spade</item>
</area>
Then use this to populate your classes in memory.
You could store the data in a file system (a zip file or a folder).
Each choice could be stored as a folder, while all descriptions, modifiers and other data could be stored as a text file (xml?). When user makes a decision you go to the appropriate folder and follow the plot.
Example:
Do you want to:
open the door (door)
leave (leave)
If user choses to open the door you go the folder door and reads data from data file in this folder.
Pros:
simple
do not require database
easy to add new adventures
Cons:
problem with rollback decision (getting back to start or to certain point in plot)
Personally, I'd avoid a database in this case, and go with a text-based file format (probably two distinct files, one for the initial state (like terrain and such), which never gets modified, and one for state that is to be modified during the course of the game (the broken windows etc.); or split the entire thing up into one pair of static/dynamic data per area.
A few reasons:
A text file is human-readable; hence, you can create content without a dedicated editor, while with a database approach, you'd either have to enter data through queries, or code a level editor
Assuming a single-player scenario, concurrency is not an issue
Savegames are a matter of copying the modified-state files into a savegame folder, or packing them into a single file
You can easily embed scripts
The data structures you're dealing with are probably simple enough for data integrity not to be a serious issue

How do you suggest I approach this unique problem?

I have a website where I allow businesses to register what products they sell individually. Then a consumer can online and search for a product and receive a list of all the shops where it's currently selling.
Although they can upload one product at a time, I want to allow businesses to mass upload things they offer.
I was thinking of using a excel spreadsheet. Have them download the template, and then have them upload the filled in excel sheet.
Others have suggested telling them to create a CSV file, but that is counter-intuitive in my honest opinion. Most likely a secretary will be creating the product sheets and she won't have a clue about what a CSV is.
What is the best way to approach this?
Well, it partly depends on the businesses. If they are medium or large businesses, they'd probably rather submit the data via a webservice anyway - then they don't have to get a human involved at all, after the initial development. They can write an application to periodically suck information from their (inevitable) database of products, and post to your web service.
If you're talking about very small companies without their own IT departments, that's less feasible, and either Excel or CSV would be a better approach. (As Caladain says, it's pretty simple to export to CSV... but you should try from a number of different spreadsheet programs as they may well have different subtleties in their export format. Things like text encoding will be important as well.)
But here's a novel idea... how about you ask some sample companies what they would like you to do? Presumably you have some companies in mind already - if you don't, it's potentially going to be pretty hard to make sure you're really building the right thing.
Find out how they already store their product list, and how they'd want to upload it to you. Then consider how difficult that would be, and possibly go back to them with something which is almost as easy for them, but a lot easier for you to implement, etc.
While I personally don't like Excel very much, it seems to be the best accepted format to do such things (involving a manual process).
My experience is that CSV breaks easily, for instance it uses the regional settings to determine the separator which can cause incompatibilities on either the client or the server side. Also, many people just save the file in any Excel format because they just don't know the difference.
Creating the files can be pretty easily done with some XSLT (e.g. create XMLSS format files, which are "XML Spreadsheet 2003" format).
You may also want to have a look at the Excel Data Reader on Codeplex for parsing the files.
Reading in an Excel file is actually pretty easy with ODBC. Tutorial on it.

Categories