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.3 beta feedback (Read 60745 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 v1.3 beta feedback

Reply #100 –
after the upgrade to f2k 1.3 beta, all playlists were moved to the new folder playlists-v1.3. i closed f2k, delete old playlists, and moved into it new, and then deleted the folder playlists-v1.3. after f2k restarting, playlists-v1.3 folder was created again. it is not convenient for me, because i use Autosave & Autobackup where specified folder playlists. if i change autobackup settings from playlists to playlists-v1.3, when a new version of f2k (1.4 or higher), which will create a playlists-v1.4 and etc., playlist's backup will not be done.

foobar2000 v1.3 beta feedback

Reply #101 –
As wildcards are supported you could use playlists* as the pattern.

foobar2000 v1.3 beta feedback

Reply #102 –
fbuser
it works. thank you!

foobar2000 v1.3 beta feedback

Reply #103 –
Quote from: high_rockin on
Quote from: neothe0ne on
Quote from: high_rockin on
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?


Working as intended.  To see the real contents instead of ".", fully load the info from the properties window's menu.


Thank you for your advice.
However, the values of these fields are not unstored in the cache, but actually set to ".".


How do you convert multiple tracks into a multi-track file?  I'd like to try this.

foobar2000 v1.3 beta feedback

Reply #104 –
Quote from: high_rockin on
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?

Bug acknowledged, thanks for reporting.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 v1.3 beta feedback

Reply #105 –
Quote from: nu774 on
Although in the change log it is written as:
Quote
Corrected gapless playback of HE-AAC files made with iTunes.

it doesn't seem to be corrected on 1.3b6.
(Strictly speaking I tested on the files encoded by qaac that is confirmed to be played back gaplessly by iTunes, since iTunes HE encoder has issues).

Have already PMed with Peter, but I also note here for anyone who cares:
This was my mistake, sorry. I tried it on specific samples that happened to yield very obvious click  between transition, and misdirected by that.

foobar2000 v1.3 beta feedback

Reply #106 –
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.

LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".
Microsoft Windows: We can't script here, this is bat country.

foobar2000 v1.3 beta feedback

Reply #107 –
This bugs me for some years now, and I wonder whether it can be fixed:

Code: [Select]
$sub(%length_seconds%,%playback_time_seconds%)
Shows correct remaining time on 100% of audio files

While
%playback_time_remaining%
Is off by 1 second in like 50% of cases

foobar2000 v1.3 beta feedback

Reply #108 –
Just two things:

Is the playlist-v1.3 folder going to be renamed only playlist? I hate to keep both folders or delete one manually.

Is LargeFieldsConfig goin to be integrated in the foobar2000 options, like someone else already suggested?

Thanks.

foobar2000 v1.3 beta feedback

Reply #109 –
Wouldn't it hurt backwards compatibility if playlist-v1.3 was renamed to playlist? I'm fairly positive that you can delete the latter without any side issues whatsoever.

Also, it was already mentioned that LargeFieldsConfig.txt is not a setting meant to be changed often, so there's no need to expose it via the main preferences.

foobar2000 v1.3 beta feedback

Reply #110 –
Quote from: Peter on
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.

LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".

Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.

I know, a very 'fuzzy' bug report but I don't have any more details right now.

foobar2000 v1.3 beta feedback

Reply #111 –
Quote from: pqyt on
Quote from: Peter on
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.

LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".

Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.

I know, a very 'fuzzy' bug report but I don't have any more details right now.

Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:

You are playing a track which does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.

foobar2000 v1.3 beta feedback

Reply #112 –
Quote from: d125q on
Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:

You are playing a track which does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.

can't confirm that, i have full filebuffering up to 99999 KB, and i'm playing a mp3 with ~10 MB, immediately after scanning and applying replaygain information to the file, the volume changes

foobar2000 v1.3 beta feedback

Reply #113 –
Quote from: d125q on
Quote from: pqyt on
Quote from: Peter on
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.

LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".

Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.

I know, a very 'fuzzy' bug report but I don't have any more details right now.

Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:

You are playing a track which does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.

I don't know which setting you're referring to but the "full file buffering" in Advanced / Playback is set to 0K. I haven't changed any settings between the last stable version and the recent beta's.

Edit: And the effect is the other way around: the tracks have had RG all the time, causing them to play 'louder'. I noticed it because of the drop in loudness.

foobar2000 v1.3 beta feedback

Reply #114 –
Quote from: pqyt on
I don't know which setting you're referring to but the "full file buffering" in Advanced / Playback is set to 0K. I haven't changed any settings between the last stable version and the recent beta's.


What happens if you set "full file buffering" to a non-zero value, 1000 kb or something?

foobar2000 v1.3 beta feedback

Reply #115 –
There seems to be a problem when using metadb_io_v2::update_info_async() - I've only just started using beta7 following a bug report, so I can't comment on previous betas. I've stepped through the code in the debugger to make sure I wasn't doing anything retarded and I don't seem to be.

The tags updated don't change in the properties dialogue, despite the console saying the file has been reopened following an edit. I haven't tested extensively, but a restart can sometimes get the properties dialogue to show the updated tag (it doesn't always). It didn't seem to make a lot of difference whether the tag was specified in the large fields text file - there were still problems when I removed the lyrics and unsynced lyrics tag names.

Thanks for all your efforts and if you need anymore info let me know

foobar2000 v1.3 beta feedback

Reply #116 –
As you've noticed, tag updates vs large field handling is a touchy subject.

With the new simplified info cache, we need to make sure that someone does not accidentally overwrite actual tags with cut down info from the cache - if the file already contains a field that's too long to fit in the cache, it's forcefully retained - unless the calling component uses a new 1.3 API to report itself as large field aware.

Stuff that you can do to mitigate this issue:

* Use the new metadb_io flag: op_flag_partial_info_aware = 1 << 3
It tells metadb_io that you're aware of partial info semantics and that large fields present in the files should not be forcefully preserved.

* Call input APIs by yourself instead of metadb_io info update, there's nothing between you and the tag writers then. You must then make sure that metadb_io gets the hints about changed file properties. This is actually pretty straightforward, not much to go wrong talking to input_info_writer etc by yourself.
This is probably the preferred method for you if you're writing a lyrics handling component, since you already have to talk to the inputs directly to read oversized fields correctly.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 v1.3 beta feedback

Reply #117 –
Sounds like a bit of a nightmare for you! Is there any particular disadvantage to using the op_flag_partial_info_aware flag? It seems to work very well with my existing code. Presumably when you set this flag it's reloading the file_info directly from the music file - then editing + saving it (updating the database accordingly)? Is that the difference between the two options you gave - whether it uses an existing an file_info or loads it from file? (assuming I implemented a similar method to update_info_async)

foobar2000 v1.3 beta feedback

Reply #118 –
No particular disadvantage to using that flag, it's meant for the exact case when your component is compatible with behaviors introduced in fb2k 1.3; not specifying that flag activates backwards compatibility workarounds.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 v1.3 beta feedback

Reply #119 –
1.3.1 beta 1:

- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.

foobar2000 v1.3 beta feedback

Reply #120 –
Quote from: eahm on
1.3.1 beta 1:

- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.

Can anyone confirm this? Because I don't know why but it seems to be working now, I swear it didn't when I wrote that, I've double checked all the tags, command, files, everything.

foobar2000 v1.3 beta feedback

Reply #121 –
I regularly use that function (and have been on 1.3.1 beta 1 since it was released), but I haven't noticed a single problem. The pattern you were using must have been wrong; well, either that, or you were seeing things.

foobar2000 v1.3 beta feedback

Reply #122 –
Quote from: eahm on
Quote from: eahm on
1.3.1 beta 1:

- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.

Can anyone confirm this? Because I don't know why but it seems to be working now, I swear it didn't when I wrote that, I've double checked all the tags, command, files, everything.

Quote from: d125q on
I regularly use that function (and have been on 1.3.1 beta 1 since it was released), but I haven't noticed a single problem. The pattern you were using must have been wrong; well, either that, or you were seeing things.

+1, I have a sequence of "Format from other fields" based edits I do every time I acquire/import new music (which I do every few days it seems.) I never noticed a problem in any of the betas.

foobar2000 v1.3 beta feedback

Reply #123 –
LargeFieldsConfig.txt is a pain in the a**, for such a major new change in doing things, the repercussions are not exactly well documented. 

I've tried adding a few items:
fieldBasic=comment
fieldBasic=DISCOGS_RELEASE_NOTES
fieldBasic=DISCOGS_RELEASE_CREDITS

After nearly 2 hours of watching my HD spin which I assumed were the new large fields being added (media library was 'monitoring'), I still ended up with a '.' where I expected info from DISCOGS_RELEASE_NOTES field. Checking the files, %DISCOGS_RELEASE_NOTES% was quite large.

If a tag is included and it is larger than basicMetaMax, is it partially displayed or completely ignored?

Assuming I can figure out the size of the largest field I want to include to set basicMetaMax=x, does that mean the cache is overly large for all of my fields?!

Also, any tips for determining what my max basicMetaMax should be set to based on existing tags?

----
Related *BUG* seems to be when rendering fields that are not cached or included in LargeFieldsConfig.txt, e.g.:

(example via Text Display component:)

[%comment% ]
['Release notes:' %DISCOGS_RELEASE_NOTES% ]
['Credits:' %DISCOGS_RELEASE_CREDITS% ]

if comment is too big and results in '.' being displayed, the rest is ignored even though they exist and are within the size limit.

foobar2000 v1.3 beta feedback

Reply #124 –
Did you restart foobar after editing the config as it's specifically stated in it?