Digital download file format discogs

Burn MP3 discs and data discs. Advanced metadata editor for easy editing of all metadata. Use as a metadata editor and edit all metadata of existing files. Keep all metadata on audio file format conversions.

Download high quality metadata and cover art from 6 online metadata services. Metadata can be retrieved automatically or searched manually with keywords. All audio codecs are included in the software. Customize MediaMonkey with Skins, visualizations, plug-ins and other addons to make it do what you want it to. Integrate it with other applications such as sound editors, metadata lookup addons, customized reports, customized views, or create custom Auto-DJ rules.

MediaMonkey Toggle navigation. Download Forum Support Addons Develop. MediaMonkey is the movie and music organizer for the serious collector. Identify Tracks. Manage Playlists. Automatic Library Updates. Try MediaMonkey if you want painless media management for almost any portable player.

If you need to manage music for a large audience, MediaMonkey is the jukebox for you. I have a similar system to GP, and the answer is yes: I will duplicate files that are relevant to multiple projects, with the exception of research papers, which all live together in Zotero. I think the author is just a little bit behind the times in terms of organizing large corpuses of inter-related data. Semantic Web stacks are one way to improve on this using taxonomies and ontologies, query languages and data specs; they almost mention it in the alternative systems "touples" but don't dig into just how hard it is to manage data using unstructured references or even structured ones!

Simple hierarchies are Tags are simple too, but they quickly devolve into new complexities as people try to figure out how to apply them, find them, organize them. Hierarchies aren't typically as difficult to manage because it boxes you into re-creating the same mental model for organization, just with different classifiers for each level of the hierarchy. They're less flexible, but they're easier to grok, maintain, and use. My major concern is that there isn't really a need to "fix" hierarchies, it's just a nagging problem that someone doesn't want to deal with, so their solution is to make something more complicated It should also be feasible to design applications to organize the files without having to rewrite filesystems.

You seem to know a lot about this; what is considered the "correct" way to organize data like this these days? I couldn't claim to know what is "correct" and what isn't!

I've just worked on projects to organize large collections of interrelated datasets for example, to update correlations between concepts, to make search engines more effective, to identify related or dependent item relationships, etc and for our project we used a Semantic Web stack.

Browsing GitHub for "knowledge graph" or "knowledge management" seems to pop up some cool looking projects, but I think everyone is still trying to figure out what works for a particular use case rather than generally. I hope a real data scientist can reply with whatever the latest and greatest solutions are. Semantic Web tech for knowledge graphs are continuing to evolve, but also kind of old, and they're still mostly used for research projects.

Part of that is probably because the terminology is unusual, and implementation leads you down a long rabbit hole of new and confusing concepts. So that's why I'm thinking that just sticking to a boring inefficient hierarchy might not be so bad My main goal is to make the data as future proof as possible, in my mind that means going with some standard filesystem hierarchies but supplementing it with photo metadata using exiftool.

While you can force write XMP standard metadata onto unsupported file types--there is a push to standardize XMP across all files--metadata support is far from standard across operating systems or tools. I then use lightroom to tag the photos with as much information that I can, especially the names of the people in the photos. This way I figure, even the least technical person can find photos from a specific family but with slightly more effort, they can also search for people across the folder hierarchy.

I've been meaning to try out PhotoStructure[1] for a while now as it looks like it might just be a good place to finally put some effort into organizing my collection. Nothing is guaranteed to last forever but it looks like the author is planning ahead in this case such that even if he goes out of business, all the work I put into organizing would not be meaningless data is stored in a sqlite db and code will be open sourced in event of business closure.

I'm the author of PhotoStructure. Hierarchical tags are fundamental to PhotoStructure! XMP or. MIE , to ensure your work isn't wasted if you migrate to another tool in the future. As far as future proof goes, Danbooru has been on the web for 15 years and on github for 10 and is still actively developed. There is a web interface and also a webapi.

But the lack of access control may be a problem. Maybe with appropriate nginx auth config you can ensure only the family can access it. If you search for it beware NSFW. ClumsyPilot 17 days ago parent prev next [—]. Our industry is totally irresponsible and run by children. I don't like the idea of file hashes for storing files.

That really only works well for a limited set of files completely ignoring things like databases, note files, etc. If you want to generate a name, UUIDs would make way more sense. Additionally, even for files which never change, what happens when a bit gets flipped inside of the file? That would presumably change the hash without knowledge of the file system until you try and read it. For drives intended for consumers, you really don't want to have more data loss than is absolutely necessary in case of minor corruption.

On a different note, I use Tiddlywiki with tags a lot for my personal notes and I think a hybrid approach with tags and a hierarchy works best. Hierarchies are useful for generating meaningful unique names where it is nice to have the notes be meaningful. You could do this automatically via the path or by some sort of rules engine.

Finally, I would really like it for a more complex information storage system to fully support 1, 2, and 3-tuple metadata. Humans probably wouldn't generate the metadata in the previous example, but it would help tools play nicely together since you could have a small static analysis tool which simply updates this metadata which could then be used by other tools or by users directly. One of the greatest things about file systems is that they allow for separate tools to interact with the same data in a structured way.

Bit flip issue could probably be solved using error correction codes in the implementation of the file system. Interesting idea using 3-tuples for storing relationships between files. Or better idea. Use directed graphs. Directed graphs are strictly a superset of both tree and tag set functionality. Tags sets can be thought as a special case of directed graph.

You make the tag a node in the graph and you make files also nodes and have edge pointing in direction of the tag node. You can then do graph queries to find files tagged in a certain way. But graphs offers so much more. Because they are superset of both trees and sets, you can use it to represent both, at the same time. It is not very useful to have a lot of things tagged the same way because you end up with just a long list of things. Whereas in a graph you could say that you want to find objects from which you can reach certain tag node and all these objects can still have their own structure and even be part of multiple structures.

For many years I had this idea to build my PIM where I could make arbitrary nodes being anything that could let me connect anything to anything. A node could be an email, a file, a link to external external website, a task, a contact, a reminder, etc. And you could connect everything to anything and have, for example a project that has important emails attached to it, the email could have attached a reminder to respond and a file that you want to include in response, and a note.

You could browse this graph as a tree because locally it could be interpreted as a tree, you open the tree one level by finding all elements that pointing to the node. Knowledge classification is not directed. I'm not sure entirely how to describe it, though "probabalistically associative" is a phrase that comes to mind.

It looks like a digraph in many local regions, but overall is not. It is not knowledge classification. It is association like this PDF file is associated with this project. Which is exactly my point.

Hierarchical filesystems can be used for classification create folders for classes, put things in right folders. But the issue is that the user has to perform classification to even be able to store the file and you can only put the file in one class so if you do that poorly you will have hard time finding it later a condition which I call disorder.

Association lets you overcome that problem by allowing you to associate the item with multiple classes. If your aim is to be able to find it later it is better to put the item in too many classes. A filesystem that only allows you to put the item in one class requires you to make a good decision immediately. Additionally, there is low cost of making a mistake when adding another association but there is comparatively larger cost of changing the classification by putting the file in another folder.

You're using the case of some directed relationships to argue for exclusively directed relationships. That is a false generalisation. Using a directed graph exclusively requires that classification assocations be strictly directed. That's simply not the case. It can appear that way in certain instances an author writes a book, a book doesn't write an author. But books influence authors, and multiple authors as contemporaries can influence one another.

Topical classifications may descend through one of several directions: a history of a technology developed in a place by a specific person might have points of entry by date, location, biography, technology, application s , or consequences. There's no single "home" for that concept, but a web a non-directed, potentially cyclic graph with multiple relationships, many bidirectional.

That leaves you with a few options: - You can abandon the directed graph and utilise an indexing and search schema which more accurately describes the relationships. Where physical storage is based on topicality, the requirement of a single locality imposes this requirement. Here a key issue is as I've described in several earlier comments that position alone is neither a guide to the content adjacent documents may be utterly unrelated , the researcher there is no streightforward exploration path to a specific record or concept , nor the curator topics must be specifically assigned and aren't inherent or evident by position.

In declaring that "it is not about knowledge classification", you've attempted to change the scope of the discussion. Even in the example you give, the case falls apart. How do you describe that set of relations in a directed graph? Are you assuming your graph is acyclic? I made a small PoC and one of the things I tried to learn was if it is possible to basically disallow creating cycles because they are a headache. I found that preventing cycles completely was irritating to me as a user as it would occasionally prevent me from making a change and require to fix the structure somewhere else before I could do whatever I wanted to accomplish in the first place.

OK, I can agree to that. Now for directed: Is a work an attribute of an author? Or is an author an attribute of a work? Are these seperate relationships? Because it seems to me they're not. Is the work-author relationship inherently directed or not? Because it seems to me you're claiming it is. We could pick other relations, that's a fairly simple, straightforward, and common case. Let me explain a little bit different way.

Look at Data Explorer. It has various types of nodes, you can define new types of nodes, and there is no restriction on how these nodes can be nested other than they form a tree. I used Ultra Recall for couple of years for my personal workflow. In a normal hierarchical filesystem you have this restriction that files are placed in folders and that's about it.

You can have multiple types of files but folders are just bags for files with not much additional data other than folder name and you can't have files nested below other files. In Ultra Recall every object regardless of type accepts child objects. I found this to be very powerful, for example, I could have an email but then write a note being a child object of the email.

Or I could create an object that was an actual working reminder. Then I could move that email to be nested under some task object and Ultra Recall had facility called "saved search" which allowed you to define a search for example for all projects that don't have next actions under them or all tasks that have deadline within next week. Some other types of nodes are actual files -- you can put a webpage or a document and these become just part of the tree.

One problem with this is that when you try to add an object you need to figure out a location. As Ultra Recall is a tree there is always one parent , when you are adding items you need to decide location ie.

For example, sometimes you have something you have vague idea you want to preserve but you just don't have time now to decide. Or an item could potentially be useful for multiple projects. But sometimes you can be sloppy with this. For example, Ultra Recall offers full text search so you are free to just dump some of the stuff in a folder and forget. When you need it you just run a search for any part of the document or its properties tags and it gets brought up.

So I created couple of "dump" folders where I could just throw stuff in like "read later". I started writing keywords at the top of documents and I could then more or less ignore when the document was placed if I could not find a good location for it.

Deciding where to put stuff is a chore when you create a lot of documents and rely of classification to find them later. But this only solves the case when you have no immediate parent candidate. What if there are multiple parents that you would like to use? For example, the parents are various projects and the child is an email that is related to those multiple projects.

I would like to be able to have multiple parents projects to which the item email is attached. So I was toying with the idea of making a little better Ultra Recall by relaxing the requirement that an item has only a single parent node. In effect, this creates a graph where any item can have multiple incoming relations children and multiple outgoing relations parents.

Just commenting to note that I'm finding this interesting and provocative. Not necessarily convincing, though I'm thinking my way through questions and concerns.

I'll throw one thought out just for grins: why do we bother with documents and records at all, and what is the value in going through old records. I'm asking far less because I doubt any value, somewhat more because I've been put this question by someone whose sanity and motives I very much doubt, and for whom no response seems sufficient , and because I think it nudges at some very-frequently unquestioned assumptions and motives about this whole endeavour.

That said, I'll try to return to and respond to your comments more directly. Nowadays we have a lot of webapps that do not store information in files the databases behind them use files but this is not important for the user.

If you notice, interoperability is pretty bad and has to be developed separately, every single time for every single use case. You can't take your "facebook file" and grep it for the contacts you are interested in or pass it to some other program. You can't make a backup by creating the copy of the file, and so on. But I digress. The issue isn't about files being a problem I don't think they are. The problem is about organizing them. There simply isn't any good organization idea implemented in practice.

People say files are too hard for normal users but what they really mean is that users are lost in a normal filesystem or they are going to be lost after they have created enough files without being super tidy. I would be glad if files themselves vanished completely from the users' view and only stayed there as an intermediate storage layer. I'm reminded somewhat of mainframe DASD storage, which has a few characteristics: - A largely flat directory structure.

A file could contain and most often did multiple different record types, as a hierarchical data file. At one point I worked in writing code to read data files, including IBM mainframe files. That was many moons ago and much of the work was not on IBM mainframes themselves, though some was. I've suppressed much of the trauma These days we tend to use an RDMBS database structured as rectangular tables with columns and rows also invented at IBM, and available on mainframes, though not often part of my previous life.

Funny thing: SQL was originally pitched as a query language that could be taught to secretaries and administrative staff to directly run queries against databases. Either admin staff were much more brilliant then, or that was an ambitious vision These have a structure and can be picked apart, though they're still fairly complex. Data interchange always needs to be specifically structured and engineered. For mostly-textual information, which is where I think of tagged systems being most appropriate, the internal structure of documents is But that still leaves us with the problem of sorting out what's where and how to access it.

I'd argue that most present filesystems are inadequate to the task of and by themselves , though they might be extended. An interesting and fairly simple example is the maildir format for storing email.

It lives on a standard filesystem, and its naming convention is opaque email message IDs. A special access program, a mail reader, provides access to the mailbox es , though other tools can provide more programmatic process.

Principle organisation is by data, though other metadata aspects can be used. As a rough proxy of what a document store might look like Backing up a bit myself, I've been trying to establish two related, but distinct points: - There is not a single unambiguous or consistent hierarchical structure to topical knowledge overall.

This is a trap numerous organisational attempts, dating to Aristotle, have fallen into. The history and attempts themselves are fascinating, for those into that sort of thing.

That is, the hierarchy as a whole is not directed. There are other alternatives, such as alphabetic ordering used in many dictionaries and encyclopedias. This works where the alphabet involved is reasonably compact, has a definitive single collation order, and entries themselves are at least reasonably distributed across the indexing scheme e. It's effectively a hash using the first character under the writing system. A work has an author, an author has works.

Similarly, two people are "in" a relationship. Remove authorship or relationship, and all the relations are removed.

Though there may be unrequited love, unrequited authorship is less often observed. This despite the fact that it is the author who volitionally created the work in the first place Tagging is a form of RDF triple. Entity has tag. That gives us object and object, but not much by way of predicate , other than "has". Your Ultra Recall example doesn't do much for me as I'm not familiar with it and can find little information online other than a CNET download link.

That said, I'm vaguely familiar with knowledge management systems. UR seems vaguely similar to Hypercard or a Wiki, though with the significant distinction in your description that UR apparently has an explicit parent-child relationship between nodes, whereas in a Wiki and AFAIU Hypercard , relationships are merely as peers.

As you note, this OTOH, there are entities which have a specified order. The collection of characters within this post would have much less utility as an unordered or differently-ordered set. Pages and chapters in a book, volumes or episodes in a series, scenes in a film, slides in a presentation The alternative I favour is for some metadata to be inherent or intrinsic, whilst other metadata is specifically assigned, created, or evolves.

In general, time may well be the most universal initial placement mechanism, that is, thinking of the system as a filesystem, date-based access is a principle access method. Pretty much all other metadata is either explicitly assigned or occurs through interactions. A work might be linked from another. It could have a specific title and subject s assigned. Translations, summaries, and reviews might be created from it.

It might be cited, or cite other works. That's all metadata, but it isn't endogenously entrinsic to the work itself. Citations of other works approach this, but still need to be distinguished from a fully endogenous characteristic as a citation references something external. An area I've been exploring but haven't really settled on or found a satisfactory standard is development of word-ngrams or tuples from within the document itself. Whitespace-delimited word clusters, ranging from typically, can be highly useful in identifying common, distinctive, and unique elements within works.

There are numerous issues with flattening the space capitalisation, stemming, spelling variants, transliterations, homophones, homoglyphs, character substitutions , but these are a powerful tool.

Ngrams are compute and space intensive , but seem quite useful. For a time Amazon offered a "statistically distinctive phrases" or similar feature for books, showing terms that occurred with far greater than typical frequency within a given work. That's been retired for years. Another space I've been exploring has been various topical classification schemes, including both the Library of Congress Classification the A-Z subject headings and subdivisions and the Library of Congress Subject Headings an independent set of descriptions frequently found in the LoC classification section of a book's publication and copyright page s.

Trying to find a single, or a sufficient-but-useful-and-not-excessive set of high-level summaries for works is its own interesting task. My sense is that much of that might be offloaded to an AI based on a known corpus the LoC have catalogued some million works, there are additional samples through published academic articles approaching m works, this might prove viable, given full-text access. And, depending on the types of works you're interested in classifying, there's the question of how to approach images, audio, musical composition, choreography, video, data, and software.

Perhaps also plastic arts sculpture or physical objects , etc. War and Peace by Leo Tolstoy is a work , the English translation is a manifestation , and the BBC teleplay on videocassette would be an instance , for example. Picard is written in Python, which is a cross-platform language, and makes use of cross-platform libraries — this allows the same code to run both on Windows, Linux and macOS.

TagScanner is a powerful tool for organizing and managing your music collection. You can rename files according to information from the tags, import tag information from filenames or other sources, perform any text replacement and transformations in tags and filenames. Also you may get album info and download covers via online databases like freedb, Discogs or MusicBrainz.

You can create playlists in one click and export your collection to HTML, Excel or any user-defined format. Program has easy-to-use multilingual interface and built-in audio player.

EasyTAG is a simple application for viewing and editing tags in audio files. And works under Linux or Windows. The usual tag editor features are supported like extracting tag information from filenames, renaming files based on their tags by using patterns and basic tag editing.

Then there are Functions, which can do things like replace text, trim it, do case conversions, etc.