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

1.3.4 beta discussion

Reply #50 –
Beta 5 up, hopefully the last beta this time.
Regression causing crashes for some people has been fixed, thank you for your patience.
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #51 –
Thanks for the update Peter!

1.3.4 beta discussion

Reply #52 –
Thnx 4 the new update

1.3.4 beta discussion

Reply #53 –
I don't know how far Matroska support is supposed to have gotten, but I just experienced this using the new beta 5:

I reencapsulated an .mp4 (AAC audio) to .mkv and also to audio-only .mka using ffmpeg (using -codec copy resp. -acodec copy -vn -sn).

fb2k plays them. Verifies them with minor problems (length mismatch). But trying to tag them:

- ReplayGain: Could not update tags (Unsupported format or corrupted file) on:
But RG gets written!

- Properties, change Artist: The same. Hitting Apply, I get the same message. I have to cancel to exit the Properties window.
And then, when I re-open the Properties window, I have to use Tool -> Reload to see that it has in fact updated. And it has - but then it has written double tags:
<COMPATIBLE_BRANDS> : isomiso2avc1mp41; isomiso2avc1mp41
<ENCODER> : Lavf55.33.100; Lavf55.33.100
<MAJOR_BRAND> : isom; isom
<MINOR_VERSION> : 512; 512

fb2k cannot remove these tags either (but it removes one of the entries - or maybe removes and then rewrites?)


Finally, the bitrate for Matroskas (and WebM) is audio+video, not merely the audio part.
And, the presumably same AAC stream (at least they bitcompare as identical) are reported as 126 in the .mp4 and 129 in the .mka.

1.3.4 beta discussion

Reply #54 –
Related to Porcus' post. Looks like ffmpeg creates broken MKVs, or at least MKVs which cannot be tagged by foobar2000. It also doesn't correctly copy over the metadata fields. So I'd strongly recommend not to use ffmpeg for muxing, and rather recommend to use MKVToolNix/MKVmerge.
It's only audiophile if it's inconvenient.

1.3.4 beta discussion

Reply #55 –
S**t. And I did presume it wasn't ffmpeg, which has had Matroska support since ages.

Edited away a "This works:". It does not.

1.3.4 beta discussion

Reply #56 –
Quote
Updated FLAC code to the latest git (as of 2014-10-07), with bug fixes and speedups [beta 5].

Just wondering, do you feel this is safe to use considering it won't be as stable/well-tested as an official stable version?
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

1.3.4 beta discussion

Reply #57 –
I don't recommend remuxing MP4 audio into Matroska.
On remuxing, information required for gapless playback (stored in the container) is lost. The latest Matroska spec finally added elements to store them, but NO remuxer will properly copy them from MP4 to Matroska. This is same for lossy codecs such as MP3, Vorbis or something. If you need gapless playback, just don't remux it into Matroska!

Moreover, seek on MKV is likely to be inaccurate ("random access test" of fb2k decoder validator should usually fail regardless of audio codec in use).
Technically, accurate seek might be possible if timecode scale is chosen properly... but usually 1,000,000 is chosen by the muxer, which means the smallest unit of timecode is 1 millisecond, which is not precise enough for audio, where 1 sample is only 0.02 milliseconds long for 44.1kHz audio.
For the same reason, TTA in Matroska cannot always be losslessly decoded... it simply can't preserve the sample accurate length of the original because of not precise enough timescale.

1.3.4 beta discussion

Reply #58 –
Good points, nu774. The discussion about using Matroska came up in the other thread regarding playback of MPEG video files which only contain MP2/3 audio streams.
It's only audiophile if it's inconvenient.

1.3.4 beta discussion

Reply #59 –
Quote from: Maurits on
Quote
Updated FLAC code to the latest git (as of 2014-10-07), with bug fixes and speedups [beta 5].

Just wondering, do you feel this is safe to use considering it won't be as stable/well-tested as an official stable version?

The code in git has been reviewed by people in charge and tested with the same tools used to verify release versions. And any foobar2000 user can run their own verifications that decoding is performed correctly easily with File Integrity Verifier component.

1.3.4 beta discussion

Reply #60 –
Quote from: nu774 on
Technically, accurate seek might be possible if timecode scale is chosen properly... but usually 1,000,000 is chosen by the muxer, which means the smallest unit of timecode is 1 millisecond, which is not precise enough for audio, where 1 sample is only 0.02 milliseconds long for 44.1kHz audio.
For the same reason, TTA in Matroska cannot always be losslessly decoded... it simply can't preserve the sample accurate length of the original because of not precise enough timescale.
The likely most commonly used Matroska muxer (mkvmerge from mkvtoolnix) has actually been doing this since 2004:
Code: [Select]
       --timecode-scale factor
           Forces the timecode scale factor to factor. Valid values are in the range
           1000..10000000 or the special value -1.

           Normally mkvmerge(1) will use a value of 1000000 which means that timecodes and
           durations will have a precision of 1ms. For files that will not contain a video
           track but at least one audio track mkvmerge(1) will automatically chose a
           timecode scale factor so that all timecodes and durations have a precision of
           one audio sample. This causes bigger overhead but allows precise seeking and
           extraction.
If it doesn't work, that's a bug and should probably be reported.

1.3.4 beta discussion

Reply #62 –
Quote from: Porcus on
Is it questionable that foo_verifier has no other issues with these (presumably corrupt) .mkv's than inaccurate length?

Is this related to ps auxw's post or to Matroska in general? If the former, it highly suggests that accurate time info is not used.
Inaccurate length can be harmless or it can be serious. It could simply be a reporting error and real decoding is bit-perfect. It could also mean that parts of the original sound is missing. Or less serious but still something that breaks for example gapless playback, added extra silent samples to the end.

Quote from: Porcus on
Quote from: nu774 on
fb2k decoder validator


Which is what?

It's a tool bundled in the foobar2000 SDK for input component developers. It allows testing that input components behave correctly under various situations, for example that seeking is sample-accurate. It can also simulate random corruption and test that decoder doesn't crash with that.

1.3.4 beta discussion

Reply #63 –
Quote from: ps auxw on
The likely most commonly used Matroska muxer (mkvmerge from mkvtoolnix) has actually been doing this since 2004:
Code: [Select]
       --timecode-scale factor
           Forces the timecode scale factor to factor. Valid values are in the range
           1000..10000000 or the special value -1.

           Normally mkvmerge(1) will use a value of 1000000 which means that timecodes and
           durations will have a precision of 1ms. For files that will not contain a video
           track but at least one audio track mkvmerge(1) will automatically chose a
           timecode scale factor so that all timecodes and durations have a precision of
           one audio sample. This causes bigger overhead but allows precise seeking and
           extraction.
If it doesn't work, that's a bug and should probably be reported.

Thanks to let me know, but another commonly used Matroska muxer (lavformat of ffmpeg) doesn't seem to do it.
And the doc of mkvmerge implies the fact that sample accuracy of audio is achieved only when the file does not contain video tracks.
This is contrary to the situation of MP4, where timescale is per-track property and is set so that sample accurate random access is possible for ALL track, always.

1.3.4 beta discussion

Reply #64 –
Quote from: Case on
Quote from: Porcus on
Is it questionable that foo_verifier has no other issues with these (presumably corrupt) .mkv's than inaccurate length?

Is this related to ps auxw's post or to Matroska in general?


It is related to those files Kohlrabi and myself have produced from ffmpeg.
Once encountering some specific tag fields (Genre is a trouble in my setup), fb2k refuses to save tag update claiming the file is corrupted or format unsupported. So on one hand fb2 claims it is corrupt, and on the other hand it claims there is just the minor problem of inaccurate timestamp.

Obviously verifier checks the decoding part, i.e. it does not truly verify file integrity. Is that an issue? Or is it just a question of whether the "File integrity verifier" label is a bit imprecise. Just think of it - it may be that one would think it is good enough functionality for the name, or a good enough name for what it does, even if it lets certain kinds of corruption pass.


(The logic nerd in me yells that it is not a "verifier" at all, it is a "falsifier"    )


[decoder validator]

Quote from: Case on
It's a tool bundled in the foobar2000 SDK for input component developers.


Thx. Then I won't bother :-)

1.3.4 beta discussion

Reply #65 –
The Matroska files are not corrupted - there is a bug in foobar2000 Matroska tag writer, which has been fixed for the next foobar2000 update. Thanks for reporting.
Microsoft Windows: We can't script here, this is bat country.

1.3.4 beta discussion

Reply #66 –
The File Integrity Verifier component can't possibly know all file format specs and verify them bit-by-bit to check that everything is right. It tests that the most important part, audio data, is uncorrupted and can be decoded correctly. With some lossless codecs it can verify that decoded audio MD5 checksum matches the original and with some formats it can check that each frame is valid and there are no CRC errors. And with others it can only notice suspicious things like large peaks exceeding digital fullscale or that reported and decoded lengths don't match. I don't think its name or behavior are misleading.

1.3.4 beta discussion

Reply #67 –
1.3.4 stable is out. Beta discussion closed.
Microsoft Windows: We can't script here, this is bat country.