I noticed a new change in beta 11 is that the option to only update tag info in the database has been removed.

I don't disagree with this as such, but I used to use it as a workaround to tag wav files when encoding them to a number of other formats (i.e. for portable and general listening).

I would turn "don't update files, only cached info" on, do a masstagger script on the wav files to tag them. Turn the option back off, and then convert the files to other formats.

With the option gone it is no longer possible to "tag" files with no supported tag formats as an error is simply shown on the console.

Would it be possible to, when a file isn't supported for tagging, only update the database? (And presumably show a warning on the console, or in the preferences, or somewhere...)

I'm sure this isn't the best way to do what you want, but you can create a cuesheet and a disc image from those .wav files.

1. Right click on all .wav files
2. Choose Convert, Convert to album image with cuesheets or chapters
3. Choose the WAV preset

When conversion to a new big .wav file is complete, a .cue file will appear in the same place as the .wav file. You can load the .cue cuesheet, and edit "tags" like you normally would.

I'm not really too worried about my previous workaround. There are plenty of other ways of doing it

That's just how I came across it and was wondering if people agreed with my suggestion, for whatever reason.

Although what you said is one way of tagging untagable files.

why not just convert them from some lossless format though? they can be tagged after all.. and it's not like you lose quality or anything either

Yeah - for your special case - how about you use another format (a taggable one) as transcoding source? And masstagger and copy tags are your friends.

Other than that, I'm hoping for an easy way to create .apl files from individual files (not only cuesheets), so they can be used as "taggable proxy files" for your collection. IMO this would (partially) solve the problem in a clean and consistent way.

Thanks for the replies.

The wav files are straight out of EAC, and get deleted once I've encoded them. I'm not too worried about my ripping process. It was just an example.

I was making a suggestion on how to handle tagging formats that have no tag support. If this is in fact only wav files, then there isn't much to worry about I guess.

I believe v0.83 did what I suggested (updating the database when there is no tag support for the file type). It just seems like a cleaner way of doing it, and in my opinion would still fit in with the "tidying up" process foobar seems to be going through.

I second this. Doing the job in v0.8.3 then importing the playlists to 0.9 will get boring, and honestly I don't see why it would now be forbidden to use foobar's library with unsupported files.

Because lossless compression can take longer? (I haven't really tried comparing the time, so I might be wrong.)

How come the option got removed? It was quite useful.

For example, making MP3s, one could create a COMMENT field which said "Released by xxxx" and that would be transferred, but there'd be no need to alter the source file. I'm sure other people could think of better examples also.

I like having the option to not change the tags in the original files. The tags created by components like foo_playcount, foo_lyricsdb, or even from replaygain scanning, are not useful to me outside of foobar2000. So I like the ability to only have the tags in the database. (I copy my database routinely, as a back up....useful when testing strings or components)

After reading this thread, I kind of like the idea mentioned by Drenholm. I never thought about it being used like that. I could see it being very useful.

I would like this option to remain as well

i'm afraid i don't see your point here.. the only time you'd have these 'encoded by' tags is if you did them yourself (since it'd be saved in foobar in stead of in the file), and wouldn't you already know that you ripped them anyway? (and why would you care about who did it anyway?)

Folks who download/trade live concert recordings like to keep up with who recorded/processed/encoded/uploaded everything so they have a pedigree of sorts for their music.

Lots of legal free concert recordings at archive.org.

Edit: But I see your point that if it's only in FB2k, then others wouldn't see the comments.

True that they would only be there in fb2k for the file you added them to. However, like Drenholm is referring to, if you use diskwriter to convert to another file, and tell diskwriter to write that tag, then it would be in that new file (not just in the fb2k database).

Yes. That way you could alter tags you feel require alteration for distribution or release without needing to alter your transcoding source. Of course I don't have many good examples of this or other reasons why the option would be useful but I'm sure there are several.

I hope this function will be reimplemented in final release sinse it was really useful with plugins like plyacount and quicktag.

This is a good feature, but I think it could be implemented in a better way then in the past...

how about having an "options section" where you can list the types of tags you only want written to the DB... (all others would be written to the file)... that way you could specify things like play_count and last_played as DB only but other tags would be written directly to the file, not to mention with the list it would be mallible to whatever your own policy's are to tagging...

second part of this would be an option bullet on the tag updating screen... where button checked would apply your "certain tags to DB only" and if unchecked all changes would be written to file (it would be nice to have the default for this behavior defined on the above mentioned options screen)...

Peace
Ross

I kind of like that idea rosshmusic. I only wish that the title of this thread were different, such that others would realize that we're talking about the ability to write tags to the database only.

Peter, didn't you forget to add this feature in final? it was really useful.

Seconded... I believe so and a few others have also expressed that opinion. Although I don't believe it's going to be reintroduced, which is a shame. +1 vote from me anyway!

The feature was not forgotten; it was removed on purpose.

foosion
so how should I use replaygain without changing files' tags?

Cuesheet?

What harm will a few replaygain tags do your files though?

Insolent

cuesheet is good enough and I use it, but it isn't very convenient to use cuesheet with many files at the same time

i don't want files' checksums to be changed, it's very important for me