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 72929 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 v1.1.6 beta

Reply #100
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.


IMO this workaround is an ugly hack. In fact, I don't see why any workarounds are even needed. ID3v2.3 supports Unicode, and there are at least two slash characters in Unicode (U+2044, U+2215), both can be used if one so wishes to put the slash character into the artist field. The ASCII slash (which by the way is not even called "slash" in Unicode) can be used as intended by specification. The reasonable workaround, if any, would be to transparently translate U+002F entered by the user to one of the above mentioned slashes.

foobar2000 v1.1.6 beta

Reply #101
OK, but does Last.fm recognise U+2044 or U+2215 as the same, "proper" slash? If not, if they're different for Last.fm, libre.fm, or whatever, it's not still ideal solution.

foobar2000 v1.1.6 beta

Reply #102
OK, but does Last.fm recognise U+2044 or U+2215 as the same, "proper" slash? If not, if they're different for Last.fm, libre.fm, or whatever, it's not still ideal solution.


I've checked - it doesn't.

I have many artists with a slash in their name (and no AC/DC in my library!), so I've forced foobar back into using ID3v2.4, which is very much the preferred solution for me. I guess I'm going to have to do this for each of the betas, as beta 2 changed me back again.

Patched-in solutions for one or two particular artists seem to me a really bad idea on many different levels. Here's a few of mine:
3/4HadBeenEliminated
Akron/Family
DJ /rupture
Domeyko/Gonzalez
V/VM
and of course countless collaborations where I want the artist name to stay as, say, Ambarchi/O'Rourke/Haino rather than the three artists' surnames.

I'm not hugely fussed, as it's my choice, but I really do think ID3v2.3 is massively flawed for this reason, and while compatibilty is worth seeking to some degree, I think this is a mistake.

foobar2000 v1.1.6 beta

Reply #103
You seem completely confused too about the tagging changes. With old versions you couldn't have used those fields with MP3 and ID3v2.3 tags but with the new beta 2 you can.

foobar2000 v1.1.6 beta

Reply #104
I also see something wrong in this thread: since beta 1 I've never seen people talking that much about the slash character in foobar but since the AC/DC fix everyone is concerned about this. Me too, but since always.

foobar2000 v1.1.6 beta

Reply #105
Beta 3. Fixes ReplayGain scanner slowdowns and memory leaks.

foobar2000 v1.1.6 beta

Reply #106
Using beta 3 and running the Replaygain utility, memory leak seems fixed, and a scan on 5k files ran at an expected speed, but the writing of tags is very sloooooow.  I couldn't find any resource constaints or otherwise detect the cause.  thanks.

foobar2000 v1.1.6 beta

Reply #107
Did you somehow disable padding for your tags? Or just enable it for previously unpadded files? Either way, if the tag size must be changed, then the whole file must be rewritten to update the tag. Padding attempts to avoid this by using a reasonably large (a few kilobytes) tag size so that any additions or removals you make will only need to rewrite the tag block at the head of the file.

foobar2000 v1.1.6 beta

Reply #108
I did not do anything deliberate to any padding, but I can see how insufficient padding would cause this.  I experienced the slow write speed with both mp3 and flac files.  When I originally ripped the files with Dbpoweramp, I understand that it added a 4k pad for tags, but whatever Dbpoweramp did, it was sufficient for rapid writing as I modified tags for the last year in Foobar and Mp3tag.  Re-running replaygain on my files in the past day is the first time I've encountered such slow write speeds (about one file per second - far slower than what I experienced in the past or when I originally created my replaygain tags).  I have not changed my computer or other hardware or software, at least knowingly in the last year, other than updates to applications and my OS (Win 7 32 bit).

I tried an experiment within Foobar to first delete the existing replaygain tag instead of overwriting it, but the deletion process was as slow as overwriting.  I also checked tag writing speed within Mp3tag, and that seems as quick as in the past - I don't see the slow writing that I now see in Foobar.  I did the Mp3tag experiment on the same files in the same location as what I was doing in Foobar to keep as many variables the same.

I guess if no one else experiences this it's no big deal, but I thought I'd mention it in case others see something similar.

foobar2000 v1.1.6 beta

Reply #109
wow... up to +/- 4 dB differences on albums with the new replaygainscanner (1.6.3) I didn't know the former version of the rg-scanner was really that much off. To my surprise, the albums were I felt I had to change the rg-values manually before are ok now and do show quite a change in dB.

Scans faster too... thank you!
Back off haters - strictly love we deal with.

foobar2000 v1.1.6 beta

Reply #110
differences on albums with the new replaygainscanner

most notably the EBU R128 based scanner takes more of the low end into account, the old scanner seemed to ignore a bit too much there. Overall I think the new one is OK. There will always be some cases that will sound a bit off, maybe less so with this new scanner.

I won't make a case for making the type of replaygainscanner user configurable, but I hope there might become a plugin available with the "old" scanner, like there has been for the new one. On some occasions I found 70's music (jazz, piano or synthesizer) more uneven and louder than with the old scanner. Tracks with a single instrument were too loud compared to busy tracks. In this case the old scanner fixed this.
This is not a case however to abandon the new scanner as, I still think, it does better in general.
In theory, there is no difference between theory and practice. In practice there is.

foobar2000 v1.1.6 beta

Reply #111
differences on albums with the new replaygainscanner

most notably the EBU R128 based scanner takes more of the low end into account, the old scanner seemed to ignore a bit too much there. Overall I think the new one is OK. There will always be some cases that will sound a bit off, maybe less so with this new scanner.


now that you mention it... the albums with the most different new rg-scan-values are extremly bass-heavy albums - like the "rhythm & sound"-albums, that are more or less a rhythmical bass-rumble really. e.g. "rhythm & sound - the versions", album-rg before: -1.35 dB, now: -5.23 dB

edit: I just had one strange thought... do you mean someone (developer) makes a subjective decision what a rg-scanner has to take into account... like "let's focus on the high end" or "let's make the low end more accountable". That would be very strange and not objective at all.
Back off haters - strictly love we deal with.

foobar2000 v1.1.6 beta

Reply #112
do you mean someone (developer) makes a subjective decision what a rg-scanner has to take into account?

Think of it as looking for a good algorithm to measure perceived loudness. There is science and testing involved, not just arbitrary decisions.
I don't think this should be discussed in this thread however. Maybe the thread about the R128scanner or the ITU-R BS.1770 measuring document can be of interest.
In theory, there is no difference between theory and practice. In practice there is.

foobar2000 v1.1.6 beta

Reply #113
Is the ID3v2 padding option enabled by default? I believe I disabled that option ages ago and can't remember whether the initial state was on or off.

foobar2000 v1.1.6 beta

Reply #114
I haven't changed it from the default of enabled.

foobar2000 v1.1.6 beta

Reply #115
Well.R128 Gain showed a perfect gain to me
But it showed the new different problem on the directx
Volume is different from playing the distributed music of both sides(as Rock and Pop) in the music divided into the center(as Classic and Jazz)


foobar2000 v1.1.6 beta

Reply #116
ERROR

When you drag a file into another application (AIMP, MPCHC ets.), the order of files is changed to an alphabetical

foobar2000 v1.1.6 beta

Reply #117
ERROR

When you drag a file into another application (AIMP, MPCHC ets.), the order of files is changed to an alphabetical


Thats own yourself isnt that?
I dont know what are you talking 'bout to

foobar2000 v1.1.6 beta

Reply #118
Beta 4 is out. It features more tagging compatibility changes.

id3v2 (mp3) changes from beta 3:
  • iTunes-private COMM frames are ignored so they don't pollute comment fields and are always preserved when retagging.
  • Added support for more iTunes-specific fields.
mp4 changes from beta 3:
  • Added support for more iTunes-specific fields.
  • Unknown or unsupported Apple metadata atoms are preserved when retagging.
RG scanner:
elevatorladylevitateme

foobar2000 v1.1.6 beta

Reply #119
Reloading worked for me after ensuring I had COMM frame tags.  First, I had to re-write the iTunes comments tags in in Mp3tag to ensure the COMMENT ITUNNORM tags were written to a COMM frame.

thanks for these changes!

EDIT: klonuo, your iTunes comment is written to a TXXX frame and combined into a single comment with the "0" information - Foobar won't fix those issues - you need to rewrite as I did and things should work.  And if you in fact have a regular comment that should contain "0", that comment should be written to a TXXX frame by itself.

foobar2000 v1.1.6 beta

Reply #120
WRT the tagging changes: I believe all my concerns have been satisfied. Kudos. Will test to make sure when I get home.

foobar2000 v1.1.6 beta

Reply #121
Installed beta 4, reloaded my MP3 tags, and I see values showing up for %composersortorder%.  Many, many thanks

foobar2000 v1.1.6 beta

Reply #122
edit:  but there's a new problem introduced in beta 4, I think.

Was the handling of the %genre% tag in MP4 files changed?  My genre tags written in Mp3tag can't be read by foobar2000.

foobar2000 v1.1.6 beta

Reply #123
I would appreciate if the last step would be gone and the header of COMMENT tags wouldn't be hidden. Mp3tags solution to use seperate fieldnames seems elegant: COMMENT HEADER = Value.

foobar2000 v1.1.6 beta

Reply #124
edit:  but there's a new problem introduced in beta 4, I think.

Was the handling of the %genre% tag in MP4 files changed?  My genre tags written in Mp3tag can't be read by foobar2000.


It seems like some genre tags are not written to the files when converting to M4A too. Works fine on a clean install of 1.1.5.