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: 1.3.4 beta discussion (Read 19348 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

1.3.4 beta discussion

Reply #25 –
@Peter

I can confirm the rar fix in beta3. All archives that contains "read only" files works.
Thanks for that.

But, now its painfully slow to start a track from an rar archive, that is allready in the library.
It takes sometimes up to 30 seconds, to play the first track.
With V1.3.3 and 1.3.4. beta 2, this was nearly instant, like unpacked files.

Sure newly droped archives to the playlist must be scanned etc.,
but playing songs from allready indexed rars in the library, starts pretty slow now.

*EDIT*
Is it possible, that the background thread that scanns the library, now block/slowsdown other rar activities?

*EDIT2*
While playing music from an rar archiv, a newly droped rar in the playlist, take up to 10 Minutes to open.

I hope that information can help to fix this.

1.3.4 beta discussion

Reply #26 –
Biozanotiker, I just tested four different albums in four different archives and they all are near instantaneous to open, I was also quickly switching between albums and tracks.

RAR, RAR5, Zip, 7-Zip, all good.

Question: Why do you keep the albums archived?

1.3.4 beta discussion

Reply #27 –
Due to unrar.dll bugs, all requests to unpack RAR archives are now serialized - another one can begin only when the previous one has completed. Note that this does not prevent concurrent reads from a RAR archive, only listing archive contents or extracting to a temporary location are serialized; not reading from already-extracted temporary files.

This causes lag in certain scenarios (background indexing in progress). If this turns out to be much of an annoyance, we'll either revert to pre-RAR5 code ( based on very old unrar source with massive patching done by myself some 10 years ago ) or try to come up with some other fix for the official unmodified unrar.dll.
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #28 –
Update: alright, if a component does timeconsuming calls from callbacks of RAR archive content enumeration, these all block all other RAR access. Next beta will fix, thank you for your patience.
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #29 –
Quote from: Peter on
Quote from: Lebon14 on
Hey Peter can you look into my low-priority issue with the Spectogram visualization?

Sorry, tried but it does not happen here, please specify additional details. How long do you have to pause in order to get it? If you have more than one visualization open at a time, does it affect all of them or just the spectrogram? What output method and DSPs are you using? [DSPs and outputs affect audio timing info which is critical for visualizations to work correctly]


I would let it sit there for at least one minute. I have one visualization and it's the spectogram. Output method: Main output peripheral. DSPs: None.

Installed components:
- TTA Audio decoder
- MIDI synthetizers
- TAK Audio decoder
- Twitter post
- Waveform Seekbar

Note: Both Waveform Seekbar and Spectogram Visualisation used to work together nicely.

Here's a demo: MEGA Download link

Thanks in advance.

1.3.4 beta discussion

Reply #30 –
Lebon14, just to be sure, do you still hear audio when the spectrogram goes blank for you? I too fail at reproducing this problem. If I keep playback paused for minutes I see a short blank spot in spectrogram but the operation resumes quickly. A short pause causes no issues at all. I have tried this with both the Default UI and Columns UI and I too have Waveform seekbar in use. And all the components you mention apart from Twitter post.

1.3.4 beta discussion

Reply #31 –
Quote from: Case on
Lebon14, just to be sure, do you still hear audio when the spectrogram goes blank for you? I too fail at reproducing this problem. If I keep playback paused for minutes I see a short blank spot in spectrogram but the operation resumes quickly. A short pause causes no issues at all. I have tried this with both the Default UI and Columns UI and I too have Waveform seekbar in use. And all the components you mention apart from Twitter post.

Of course, I hear audio. Also, in my video above... After I cut, it came back but like, 10-15seconds later without doing anything instead of the 1 second it usually takes.

I also noticed this with some FLAC 24-bits files (see the right pane):


The bitrate is displayed as 16-bit for some reason... :\

1.3.4 beta discussion

Reply #32 –
You first said the spectrogram is blank until track changes. But now you say it returns automatically. If it loses sync by being paused for too long it will be blank for the duration of your output buffer. In a clean default install that is exactly one second. You have configured your output buffer to be 10-15 seconds.

FLAC bitrate is low if the audio signal is simple enough. As an example 24-bit stereo file with nothing but silence requires 2 kbps. Usually 24-bit material has a lot of noise in the lower bits increasing the bitrate.

1.3.4 beta discussion

Reply #33 –
Quote from: Case on
You first said the spectrogram is blank until track changes. But now you say it returns automatically. If it loses sync by being paused for too long it will be blank for the duration of your output buffer. In a clean default install that is exactly one second. You have configured your output buffer to be 10-15 seconds.

FLAC bitrate is low if the audio signal is simple enough. As an example 24-bit stereo file with nothing but silence requires 2 kbps. Usually 24-bit material has a lot of noise in the lower bits increasing the bitrate.


Buffer? Dang! That's the problem! I changed the value sometime ago because I couldn't play foobar2000 while playing a game without lag. I changed the value thinking it would help (but didn't). Reverting right now... and that fixed it. Flase alarm after all.

I know how FLAC generally works bitrate-wise. I'm looking at all the other 24-bit files in the soundtrack playing in the screenshot above but this one seemed incredibly low compared to the others where they were all over 1400 kbps. As you can see too, from the screenshot, is that the current one playing as a bitrate of 1504kbps. You can also see that the song isn't too complicated too from the Spectrum seekbar too. So, that's why I'm thinking there's something wrong with the display here.

1.3.4 beta discussion

Reply #34 –
Beta 4 out. Hopefully all RAR quirks are now gone. Unrar.dll has been dropped, back to using UnRAR source directly with own patches to decompress to memory rather than to temp files.
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #35 –
Thank Peter for the update. Little fix: the update didn't remove avcodec-fb2k-55.dll and avutil-fb2k-52.dll.

1.3.4 beta discussion

Reply #36 –
I do not have WinRAR installed so I cannot test (and don't really care, although I admit to curiosity), but is RAR5 still supported?

This is a nice library that supports reading from many archives (I do not know if it is well-suited to be used within foobar2000, or even if it supports RAR5), but I can't seem to find any references in English.

1.3.4 beta discussion

Reply #37 –
Quote from: d125q on
I do not have WinRAR installed so I cannot test (and don't really care, although I admit to curiosity), but is RAR5 still supported?

This is a nice library that supports reading from many archives (I do not know if it is well-suited to be used within foobar2000, or even if it supports RAR5), but I can't seem to find any references in English.

Chrome - Right click - Translate to Your Language

Changes http://www.bandisoft.co.kr/sdk/ark/history/ shows that it supports RAR5 and yes, Bandizip is awesome. I use 7-Zip but I think Bandizip is the best around.

1.3.4 beta discussion

Reply #38 –
Quote from: eahm on
Quote from: d125q on
I do not have WinRAR installed so I cannot test (and don't really care, although I admit to curiosity), but is RAR5 still supported?

This is a nice library that supports reading from many archives (I do not know if it is well-suited to be used within foobar2000, or even if it supports RAR5), but I can't seem to find any references in English.

Chrome - Right click - Translate to Your Language

Changes http://www.bandisoft.co.kr/sdk/ark/history/ shows that it supports RAR5 and yes, Bandizip is awesome. I use 7-Zip but I think Bandizip is the best around.


That is nice and all, but what about the library's docs? Are you gonna use Google Translate on that as well? I don't think it'll work well.

1.3.4 beta discussion

Reply #39 –
RAR5 is supported.
Before ( pre 1.3.4 ) we used UnRAR source from some 10 years ago, with a lot of patching done by myself to read data from fb2k file object and unpack to memory.
Now we use the latest UnRAR source, with minimal patching done to comply with fb2k requirements (multi thread safe, unpack to memory).
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #40 –
@Peter
It seem that all rar5 problems are gone. Thanks for that, I really really appreciate that!
Is there any reason, why only rar archives with ".rar" extension are detected, instead of using magicbytes?

@eahm
Quote
Question: Why do you keep the albums archived?

Personaly, I put all my data into rar archives, because:
- All data e.g. from an album is in one file, very practical.
- You can store data uncompressed, so (with rar5's quick open) access to data is nearly fast as unarchived files
- Rar archive supports of recovery records, this protects against "flipping bits" caused by hardware fails
- Easily check data integrity, by checking all rar archives at once.
- Protects against unwanted changes, e.g. accidental changing tags etc. by foobar or other tools, by locking the archiv with "-k" option.

1.3.4 beta discussion

Reply #41 –
Quote from: eahm on
Little fix: the update didn't remove avcodec-fb2k-55.dll and avutil-fb2k-52.dll.

The same for the, no longer needed, unrar.dll from beta's 1-3.
In theory, there is no difference between theory and practice. In practice there is.

1.3.4 beta discussion

Reply #42 –
I found wavpack file with 32 bit floating point, that foobar can't correctly decode (1.3.3 and 1.3.4 beta 4). Sound is totally distorted. If file is decoded to wav (also 32 bit floating) using Adobe audition, then it is playing correctly in 1.3.3 and 1.3.4. Also, original wavpack file is playing correctly in foobar2000 v 1.1 (not tried other old versions).
File: https://www.dropbox.com/s/b3aps30he3pww0o/U...xdown__.wv?dl=0

1.3.4 beta discussion

Reply #43 –
foobar2000 1.3.4 and wvunpack decode it into 32-bit integer WAV. While Audition 3.0 (with wavpack plugin) decodes it into 32-bit float WAV.

wvunpack -s writes "32-bit floats at 48000 Hz"
wvunpack -w writes "can't create valid RIFF wav header for non-normalized floating data!"

(maybe data about audio format in wavpack header contradict to WAV header?)

1.3.4 beta discussion

Reply #44 –
Quote from: lvqcl on
(maybe data about audio format in wavpack header contradict to WAV header?)

Indeed. If you edit wFormatTag in the RIFF WAV header to 3 like this, it should play fine on fb2k:
Code: [Select]
 printf '\x03' | dd conv=notrunc of=Untitled_mixdown__.wv bs=1 seek=$((0x36))

However, the edited file still doesn't seem to be decoded correctly by wvunpack.
It seems OPEN_NORMALIZE flag is required to be set when opening the file, which wvunpack doesn't but adobe Audition plugin and direct show filter (and probably fb2k) do.
 

1.3.4 beta discussion

Reply #45 –
I think I know what's going on here. This file was generated by Cool Edit or Audition, probably with the WavPack plugin, but it could have also been the WavPack command-line version (using the -a option) on a WAV file generated by Audition. These are non-standard in that the WAV header indicates that they are 32-bit integer but the audio data is really 32-bit float normalized to +/- 32768.0, iirc. WvUnpack does not normalize these on unpack because it's supposed to be lossless.

When a program uses the WavPack library to decode and play these files it normally works fine because the file is reported to the caller as a 32-bit float file and if the OPEN_NORMALIZE flag is set then the data will be shifted to the standard +/- 1.0 range. This is because WavPack knows exactly what this file is, despite the goofy WAV header.

The reason that foobar2000 has trouble with this file now is that about a year ago Peter changed the mechanism to detect the file formats to trust the WAV header instead of what WavPack reported. This was done to support the experimental switch --store-floats-as-ints which I put in to temporarily handle 16 and 24-bit float files. It turns out that WavPack gives decent compression of these files by just treating them as integers, and the WAV files are still perfectly restored by wvupack because the WAV header indicates that they are actually floating point data (even though not 32-bit), but they obviously will not work with existing players (besides foobar2000) because WavPack thinks that they are integers and reports that to the caller (which then plays them as loud distortion).

Because I did not believe that these audio data formats would catch on (and still don't), I did not want to spend a lot of time making sure they are correctly handled all through the ecosystem, and this is why the switch is not documented.

1.3.4 beta discussion

Reply #46 –
Since floating-point files are up into the discussion:

fb2k happily converts floating-point PCM .wav files to FLAC without warning, and that is questionable behaviour. (The FLAC reference tool terminates with error.) I suggest it should give a warning of the type given when attempting to convert lossy to lossy. And suggest a format that can contain it (WavPack that would be).

No, I do not claim that I can ABX a 32-bit floating-point from a 24-bit FLAC. But I do claim that the "lossless is lossless" maxime is too valuable to be messed with.

1.3.4 beta discussion

Reply #47 –
Updated to beta 4 and it randomly crashes on me, never had any problems with 1.3.3 and didn't change anything about my installation except for updating.
I think it might have something to do with my music library being located on a samba share.

The weird thing is that it's not the usual "corrupted track" message popup that appears if you resume playback after suspend. As you will see from the log (i sent the report), it played 2 tracks fine before just randomly dying in the middle of the third track. It sounded like a buffer underrun, the music suddenly stuttered, then foobar died.

edit: and it just blew up playing the same track again. foo_verifier shows no issues with integrity. Reverted to 1.3.3 and no problems so far.

1.3.4 beta discussion

Reply #49 –
Quote from: Biozanotiker on
Is there any reason, why only rar archives with ".rar" extension are detected, instead of using magicbytes?

All inputs and archive handlers require explicit file name matches, no magic bytes checking goes on anywhere until a file name match is confirmed. The only thing even approaching blind archive tests is the unpacker service, which only select inputs, such as foo_gep VGM, foo_midi, and foo_dumb query this service, which runs through all registered unpacker services until one of them manages to open the archive. The unpacker service, by design, blindly unpacks the first file in the archive which does not appear, by its filename, to be a plain text file.

I'm sure you're welcome to propose that the next generation of foobar2000 perform magic bytes testing, using byte test lists offered within the component services which handle the file types.

I'm thinking this would optimally be one or more file offsets, with matching bytes and masks. Perhaps also and/or rules between each match rule. Or hell, make the whole thing a series of regular expressions.