HydrogenAudio

Lossless Audio Compression => FLAC => Topic started by: Jetro on 2021-02-27 15:09:31

Title: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-02-27 15:09:31

First question:

If I use that command (metaflac.exe --dont-use-padding --remove-all), what information I lost?

I have read official documentation (xiph.org/flac/documentation_tools_metaflac.html), but I'm not 100% sure what I'm doing.

I know that I loose all tags, flac version info (metaflac.exe --version) and padding (empty space), but is there more information that I don't know?

My goal is to make .flac files "tight" and optimized.

Source of my .flac files are: CD / Exact Audio Copy v1.1 / flac.exe v1.3.1 without any information added.

I think that they contain only flac version info and padding.


Second question:

I have made "InsertTagsToMyFlacFiles.cmd" -script and it is ANSI/1252 encoded, because some tag values contains special characters.

Do I have to use "--no-utf8-convert" -option when inserting new tags (metaflac.exe --no-utf8-convert --set-tag=...) ?

As far as I know, all .flac tags are UTF-8, so why do I have to allow/deny conversion if only UTF-8 is valid/accepted?
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Octocontrabass on 2021-02-28 04:30:55
I know that I loose all tags, flac version info (metaflac.exe --version) and padding (empty space), but is there more information that I don't know?
You also lose the seektable. Files without a seektable will still play, but you might notice it takes longer to jump to different points in the file, and some players might refuse to seek entirely.

If you want the files to play like normal, I suggest keeping the seektable.

Do I have to use "--no-utf8-convert" -option when inserting new tags (metaflac.exe --no-utf8-convert --set-tag=...) ?

As far as I know, all .flac tags are UTF-8, so why do I have to allow/deny conversion if only UTF-8 is valid/accepted?
FLAC tags can only be UTF-8, but your command prompt can use a different encoding. Metaflac will try to automatically convert between UTF-8 and your current command prompt encoding.

If you're reading tags from a file and you know the file is already UTF-8, you would use the "--no-utf8-convert" option to tell metaflac that it doesn't need to convert from the local encoding to UTF-8. (It also works for writing tags to a file.)
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: danadam on 2021-02-28 04:55:24
If I use that command (metaflac.exe --dont-use-padding --remove-all), what information I lost?

I have read official documentation (xiph.org/flac/documentation_tools_metaflac.html), but I'm not 100% sure what I'm doing.

I know that I loose all tags, flac version info (metaflac.exe --version) and padding (empty space), but is there more information that I don't know?
On https://xiph.org/flac/format.html you can see that there are the following blocks possible:
--remove-all --dont-use-padding will leave only STREAMINFO.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-02-28 21:21:20
Thanks @Octocontrabass and @danadam.

I made few quick tests with my PC (MPC-HC v1.7.13 x64) and I didn't notice anything difference, with or without SEEKTABLE.
No delays when seeking.

And when I tested "--no-utf8-convert" -option, output file is same (SHA1), with or without that option.

I'll have to read more metaflac documentation and think what I'm gonna do, but basically, if my .flac files are archived and/or I play them continuously, I don't need SEEKTABLE...
And I can add SEEKTABLE later, if I need it...
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-03 15:17:07
One more question about this subject:

What does it mean "is last: true/false" when typing "metaflac.exe --list Filename.flac" -command?

My current files VORBIS_COMMENT -block is not last (is last: false), but when I remove all blocks (metaflac.exe --dont-use-padding --remove-all) and then add VORBIS_COMMENT -block, it changes to last (is last: true).
Is this important?


And previous discussion about the seekpoints, seems that Exact Audio Copy -program use 10 -seconds seektable, so I have to add "--add-seekpoint=10s" -option to my batch.cmd if I want them back...
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Porcus on 2021-04-03 22:52:43
My goal is to make .flac files "tight" and optimized.

But why? Most of us find that metadata has high information value compared to the little space taken up, so bulk removing everything is not optimization - rather the contrary.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-04 09:48:23
Why do I have to keep extra information in my .flac -files if I don't need them and most of "you" does?
It only deletes few bytes.

I have rip, encoded and tagged my .flac archive different settings over the years, so now I'm gonna make all of them same.
Meanwhile, it is good chance to ask a question: Do I actually need this feature, tag, ... ?

If I know what information I'm gonna delete, how to get it back and what are the risks, it's my own decision to make that move.

You don't learn anything, if you don't questionable things.
Few months ago, I didn't know what is "flac block" or what blocks my .flac's have.
Now I know :)


Btw, I figured out what "is last: true/false" -means.
It tells is that block last or is there more block(s) after that.

My current .flac files has PADDING -block after VORBIS_COMMENT -block, so PADDING -block is last and VORBIS_COMMENT -block is not.
If I delete PADDING -block, then VORBIS_COMMENT -block becomes last block.
Obviously :)

If there are only one mandatory block (STREAMINFO), then it is always last.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Porcus on 2021-04-04 11:26:11
If you really want to squeeze it down to minimal size, then you should rather ask how to compress the audio. Probably you would use OptimFrog for maximum compression. If you are restricting yourself to FLAC, try non-subset and/or possibly a different FLAC encoder. E.g. ffmpeg at level 12 with brute force.

For example. Hard to tell when you don't want to say why you are considering this or that option.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-04 13:36:45
The main point is to remove everything that I don't need and optimize .flac's for my needs.
Not minimize the file size.
And only with official flac tools for compatibility reasons.

I have chosen flac format, because it is open source, royalty free, most common and so on...
My .flac's are -8, so there's nothing more that I can do about that.
File size is more important to me than decoding speed.

I can't delete STREAMINFO -block and I don't even want to.
I don't need SEEKTABLE and PADDING -blocks, so I delete them.
I only need VORBIS_COMMENT -block for tags.
Nothing else.

Is there more information inside the .flac's that I can remove/optimize with official tools (flac.exe, metaflac.exe)?
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-04 15:31:24
Seekpoints -feature was first introduced almost 20 years ago, computers are much faster now.
Maybe it is useless today...

And little correction to my previous post:
The 10 -seconds seekpoints are not Exact Audio Copy's feature, it's a flac.exe's default setting.

FLAC 0.10 (07-Jun-2001)
A new metadata block SEEKTABLE has been defined to hold an arbitrary number of seek points, which speeds up seeking within a stream.

FLAC 1.1.0 (26-Jan-2003)
flac now defaults to -S 10s instead of -S 100x for the seek table.
New --add-seekpoint option to add seekpoints to an existing FLAC file.

xiph.org/flac/changelog.html
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: danadam on 2021-04-06 19:03:24
My .flac's are -8, so there's nothing more that I can do about that.
This is just a preset, equivalent to:
Code: [Select]
-l 12 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2);punchout_tukey(3)
In theory, you could fiddle with those or add others (e.g. -e) to try get better results.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Porcus on 2021-04-06 19:28:40
Sure, but it is not at all given that this has anything to do with this user's private definition of "tight" and optimized ...
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: kode54 on 2021-04-06 22:16:43
Also, the settings associated with -8 are the highest that are guaranteed to be supported by most devices. Anything higher is not guaranteed to work with older decoders.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Porcus on 2021-04-06 23:40:04
-p -e are still subset, and also new -8 is not only different from old -8, it uses new apodization functions that were only introduced in 1.3.1.

(Also there were buggy devices that could not do -8 - and that was even old -8I think I remember there was an issue with some version of Squeezebox (I think), but that was subset-compliant files and so many years ago that it had to be old -8.)

Do you perchance mix up with ffmpeg's compression levels "11" and "12" which are not subset - or what flake did in the 200somethings?
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: kode54 on 2021-04-07 02:01:21
Also I was referring to non-subset settings from FlacCL, which is a terribly useless thing to run on any modern system anyway, as you'll likely get way better encoding speed from queueing up multiple instances of flac.exe or flake.exe.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: danadam on 2021-04-07 02:02:02
Not saying it would gain you anything, but increasing -r (max residual partition order) to 8 is still a Subset. And for hires (> 48k), increasing -b (block size) and -l (max lpc order) is also a Subset.

Last time I checked, ffmpeg at 10 (or maybe even 8 ) was consistently better than flac for hires. I thought maybe it was because ffmpeg used 8192 block size, but it didn't change much with flac.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-07 16:52:20
Thanks @danadam

I'll test and edit these compression settings some day, but "officially" I'll stick to -8 for compatibility reasons.
For now.

If I remove SEEKTABLE -block, it should only slow down/refuce to seek, not break compatibility, so that should be safe "optimization".

Maybe I keep my .flac -files archived and convert all of them to .ogg (-q 10) for normal and daily use...
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: kode54 on 2021-04-07 21:04:38
Don't forget that SEEKTABLE is never actually fully 20MB, except in really large files. The SEEKTABLE block shouldn't be that large in files which are only 5-20MB, in which case it may be a few kilobytes. You will likely notice the decoding delay on slower media, such as 5400 RPM hard drives, or eMMC.
Title: Re: Metaflac.exe --dont-use-padding --remove-all
Post by: Jetro on 2021-04-07 22:46:31
Don't forget that SEEKTABLE is never actually fully 20MB, except in really large files. The SEEKTABLE block shouldn't be that large in files which are only 5-20MB, in which case it may be a few kilobytes. You will likely notice the decoding delay on slower media, such as 5400 RPM hard drives, or eMMC.
Yes, I know.
Seekpoints adds only "few" bytes :)

But 10 second interval between them sounds quite long gap.
If I add them, maybe I should put them every 1 or 5 seconds, so that they really matters.

Like I said before, I didn't noticed anything different when I played NoSeekpoints.flac -files in my devices.
As far as I can remember.

There is no hurry, I can test and think forever, while listening those imperfect .flac's with seekpoint and padding -blocks included ;)