Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foobar2000 v1.1.6 beta (Read 72916 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 v1.1.6 beta

Reply #75
You are supposed to read the change log and see that a new ReplayGain scanner has been employed.

foobar2000 v1.1.6 beta

Reply #76
Are you looking for something more detailed than what is in thread's first post? Differences are expected and dev's consider new method superior.
There are a couple of other threads here documenting using libebur128 as engine for replay gain settings.

Edit: slow


foobar2000 v1.1.6 beta

Reply #78
You are supposed to read the change log and see that a new ReplayGain scanner has been employed.


Duh. Obviously, that's why I scanned some albums AGAIN. But 4db difference??

foobar2000 v1.1.6 beta

Reply #79
The difference varies per track. On average, the results should be similar across a broad set of tracks.

foobar2000 v1.1.6 beta

Reply #80
@for4saken
After reloading BAND is mapped to TXXX(Band) which is empty. Probably ALBUM ARTIST shows TPE2 and TXXX(Album Artist) frame. I ask myself how is it possible to copy the old content of TPE2 to TXXX(Band)?

I assume, though correct me if I'm wrong, that a "Rewrite file tags" will suffice.

I did a quick test and that won't work because it will show the same result like in for4sakens screenshot. So the question remains: does anybody has an idea how to copy content of TPE2 to TXXX(Band) after reloading info? The problem is that TPE2 and TXXX(Album Artist) is mixed together under the field ALBUM ARTIST.

Edit:
I think the best is firstly to uncheck the option in advanced preferences that maps TPE2 to ALBUM ARTIST and then to do the copy job by using a dummy field. After switching back the content of this dummy field can be copied to BAND. This naturally can be done before updating to newest foobar2000 version. If there is really no good solution to do the job after rewriting file tags so that should be mentioned somewhere and an advice should be given how to save the old content.

foobar2000 v1.1.6 beta

Reply #81
@for4saken
After reloading BAND is mapped to TXXX(Band) which is empty. Probably ALBUM ARTIST shows TPE2 and TXXX(Album Artist) frame. I ask myself how is it possible to copy the old content of TPE2 to TXXX(Band)?

I assume, though correct me if I'm wrong, that a "Rewrite file tags" will suffice.

I did a quick test and that won't work because it will show the same result like in for4sakens screenshot. So the question remains: does anybody has an idea how to copy content of TPE2 to TXXX(Band) after reloading info? The problem is that TPE2 and TXXX(Album Artist) is mixed together under the field ALBUM ARTIST.

How about re-installing an earlier version of foobar, copying TPE2 -> some temporary tag (eg. NEWBAND), and then re-installing the latest version and moving NEWBAND -> BAND?

Or maybe use Mp3Tag to do the tag change.

foobar2000 v1.1.6 beta

Reply #82
That won't work after rewriting files either by context menu or by tagging something else through properties window. The content is then merged together in one frame.

foobar2000 v1.1.6 beta

Reply #83
Quote
In case an ITUNESCOMPILATION tag is found in a file, foobar2000 treats it as if ALBUM ARTIST was set to "Various Artists".


What means: treats it as if ALBUM ARTIST was set to "Various Artists" ???
Is there something special when i set it to "Various Artists"? 

foobar2000 v1.1.6 beta

Reply #84
Having any %album artist% value results in "something special"--tracks that wouldn't group together correctly with title formatting, do.

If there is no value in the ALBUM ARTIST tag and the ITUNESCOMPILATION frame is set, then %album artist% is displayed as Various Artists, so that the compilation groups together correctly.


The point of these changes is that you shouldn't have to understand any of this and it should work how you expect. If you can't wrap your head around the theoretical changes, then just use it and let us know when something you don't understand happens.
elevatorladylevitateme

foobar2000 v1.1.6 beta

Reply #85
That was ironic.
Of course ALBUM ARTIST is used for grouping/sorting etc.

btw
It would be nice if this "auto-sting" Various Artists would be customizable. I prefer the abbreviation VA

foobar2000 v1.1.6 beta

Reply #86
Quote
ID3v2.3 tags are now written by default, without unsynchronization.

Although that might make it simpler for certain tag reading routines (in other software than fb2k), what about the impact for the audio part? Are there (old?) players around (maybe in hardware/firmware) where unsync saves the day? Could audio glitches occur because of this?

(I'm sorry that I could not find answers by testing myself, most things I have used had no problem to read the ID3v2.4 with unsync. Hey, at least I don't say it's wrong upfront)
In theory, there is no difference between theory and practice. In practice there is.

foobar2000 v1.1.6 beta

Reply #87
It would be nice if this "auto-sting" Various Artists would be customizable. I prefer the abbreviation VA

I second this suggestion. Since this feature seems to be (at its core) an arbitrary TPE2 assignment in order to achieve better grouping of tracks in the playlist, it might as well be truly arbitrary to the user's preference.

As an aside, I have already been tagging VA albums without a specific album artist with "Various Artists" in foobar2000's "Album Artist" tag, and matching the same to an existing BAND tag if I have one from services like MusicBrainz, et al. Can I assume my tagging will suffer no serious consequences by this change? I have been avoiding the beta this time because I'm still not quite sure how this will work, but trust everything will reach an "acceptable" consensus by the final release.

foobar2000 v1.1.6 beta

Reply #88
btw
It would be nice if this "auto-sting" Various Artists would be customizable. I prefer the abbreviation VA

That should be unnecessary as you can just fill in ALBUM ARTIST with whatever value you actually want.
elevatorladylevitateme

foobar2000 v1.1.6 beta

Reply #89
I am having some difficulty with beta 2's multivalue delimiter.

Firstly, my understanding was that this value/symbol (be it '; ' or ' / ') was merely the representation of an actual delimitation character (say, NUL); and it was this NUL delimiter that is written to the tag when the aforementioned symbol was encountered.

However, in beta 2, when ' / ' is specified, what is actually written to the tag seems to be space-NUL-space rather than simply NUL (as interpreted by mp3tag, dbpoweramp and beta 1). Beta 2 interprets this space-NUL-space as the delimiter (and thus displays it properly) but breaks on tags written by mp3tag. If I specify in mp3tag to write ' / ', beta 2 interprets the tag properly.

To be crystal clear, here is an example of how an artist tag is displayed:

in beta 1:
mp3tag: Lore/Brennan
foobar: Lore, Brennan (Properties: Lore; Brennan)

in beta 2:
mp3tag: Lore/Brennan
foobar: Lore/Brennan (Properties: Lore/Brennan)

mp3tag: Lore / Brennan
foobar: Lore, Brennan (Properties: Lore / Brennan)

what I expected:
mp3tag: Lore/Brennan
foobar: Lore, Brennan (Properties: Lore / Brennan)

The example holds regardless of which program does the actual tag writing.

foobar2000 v1.1.6 beta

Reply #90
Firstly, my understanding was that this value/symbol (be it '; ' or ' / ') was merely the representation of an actual delimitation character (say, NUL); and it was this NUL delimiter that is written to the tag when the aforementioned symbol was encountered.

NUL is the actual delimiter character in id3v2.4 But, The slash character (/) is the actual delimiter character in id3v2.3. However, people also want to store slash characters in tags, but they technically can't. So this whole " / " thing was devised as a compromise to allow people to have multiple values in some cases (when the slash is surrounded by spaces) and to allow people to display AC/DC (where the slash isn't encased in spaces) in other cases.

Admittedly, there's no perfect solution to this problem, but this is the compromise which allows use to write id3v2.3 tags that are compatible with other software (e.g. all Microsoft software) by default.
elevatorladylevitateme

foobar2000 v1.1.6 beta

Reply #91
If tdurjan101's observations are true, then I think Beta 1 was the way to go. The very very few artists like AC/DC don't justifiy such a change. The better way IMO would be to have a list of artist strings. I heard in WMP, AC/DC was hard-coded. foobar2000 could have a soft-coded list of such artists that users can change on their own.

foobar2000 v1.1.6 beta

Reply #92
foobar2000 could have a soft-coded list of such artists that users can change on their own.

I'm missing how that would help compatibility with other programs.
All this proves that the id3v2.3 spec is the can of worms we already thought it was . Not defining a way to escape '/' is a plain oversight.

I noticed that in other tags where I use multiple values occasionally (composer, genre) the same strategy as with Artist is applied (i.e. ' / ' as delimiter) (not sure what other programs do with the extra spaces in genre). Except in comment, is multivalued comment a bad idea?
In theory, there is no difference between theory and practice. In practice there is.

foobar2000 v1.1.6 beta

Reply #93
Now that the ReplayGain scanner now uses libebur128, I am having slowdowns when ReplayGain scanning a track that has large areas of silence.
It slows down to ~2x.
Is anyone else experience this?

foobar2000 v1.1.6 beta

Reply #94
It's funny, as of 1.1, foobar2000 changed to use / instead of NUL as the delimiter. This is compliant with the spec and fixed the "compliance issue" described here: http://www.id3.org/Compliance_Issues

I posted to the id3 mailing list to try and get the line removed. Bizarrely, pretty much everyone who's posting to the list prefers the NUL approach, even though it's less compliant with the spec. PaulTaylor, who added the issue, wrote: "Actually, I agree you would be better keeping the null sperator option even though it is not compilant"

foobar2000 v1.1.6 beta

Reply #95
Are you looking for something more detailed than what is in thread's first post? Differences are expected and dev's consider new method superior.


I also would like to understand better why this engine is superior, if it is significant change. Many songs I have that were -10.00 are now -12.00dB.

foobar2000 v1.1.6 beta

Reply #96
I trust you are not asking for me to find the threads for you to read?

EDIT: removed my edit as it makes subsequent reply nonsensical.

 

foobar2000 v1.1.6 beta

Reply #97
Absolutely not.

Edit:
What I suggest is that one concentrate more information on this thread, because more people will ask about the new ReplayGain. Or perhaps explain the benefits, in short words. Something like "well it scans the true peak and makes a calculation off that information". You see, nothing scary. It will be good to know if it's worth re-scanning something like 500GB of music.

foobar2000 v1.1.6 beta

Reply #98
Yes, I have a lot of music that sounds like it needs to be rescanned (otherwise what is the point).  I'd like to know what makes the new library better, before spending many many hours rescanning everything.

foobar2000 v1.1.6 beta

Reply #99
It will be good to know if it's worth re-scanning something like 500GB of music.
There won't be that much benefit. The two algorithms are quite similar in most cases. It's not a big deal. I certainly haven't bothered to rescan my whole library. If you want technical details, you can find them here at Hydrogenaudio. Note that the details will be technical; the only differences between the old and the new approaches are also quite technical. As far as the end-user goes, they're close enough.

If anyone cares to actually collect enough data to make a compelling argument for the old algorithm or to make the algorithm user-selectable, they're welcome to do so. Be forewarned, though: Unless you actually are prepared to make a solid case for the old one over the new, you're probably just going to be ignored. Most of us who are aware of the technical details tend to agree that the new is preferable.