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: WAV to FLAC "uncompressed" (Read 2346 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WAV to FLAC "uncompressed"

hello,
i have a little problem that i am facing,
first ... im using windows 10 ...
im trying to convert from WAV to FLAC 0% compressed.
i have tried several apps and even online converting websites and i'll always get results of compression ...
simply put : i just want to convert wav to flac UNCOMPRESSED ....

anyone can help ?
thank you in advance...

Re: WAV to FLAC "uncompressed"

Reply #1 –
What is your reason for wishing to do this?

Re: WAV to FLAC "uncompressed"

Reply #2 –
Its called LOSSLESS compression. You want that. You dont want LOSSY compression. There is no benefit using flac if you did this. might aswell keep the wav.

https://www.reddit.com/r/Soulseek/comments/19fj6oy/i_ripped_two_albums_to_flac_one_reaches_22_khz/
Are these your posts by any chance? You are stirring up quite a lot of audio communities i am in with how you delete and repost questions. ^^

Re: WAV to FLAC "uncompressed"

Reply #3 –
Flac "uncompressed" as in an output guaranteed to be bigger than the input would have to be verbatim encoding with escape coded residual. Seek performance would possibly be impacted slightly by using escape coded residuals everywhere (more likely to have erroneous sync-matching pattern within residual) as a mild negative. Where's the positive?

Re: WAV to FLAC "uncompressed"

Reply #5 –
Why do we assume there is no valid technical or academic reason they may want to experiment with a non-compressed FLAC file?
I don’t have the answers for them, nor would I use this, but I don’t pretend to understand every use case either.
It is at the very least an interesting question posed on a message board that has been stagnant and uneventful for what feels like months.
I don’t think it’s very fair to dismiss them with non-answers and information they never asked for.
Compression is one of the biggest benefits of the FLAC format, and I like to go in the opposite direction - chasing the most extreme compression ratios within a subset compliant FLAC file - but even with that entirely off the table, there would still be other benefits purely as a PCM container format over something like WAV, AIFF, or such files in a ZIP/RAR archive.

Re: WAV to FLAC "uncompressed"

Reply #6 –
I stand corrected. In any case the result is the same, the raw sample being stored as-is, meaning erroneous sync patterns that happen to be in the input being present verbatim in the output.

There is technically a benefit then actually*. If wasted bits is always set to 0, then the subframe header is byte aligned, meaning the verbatim body is byte aligned and the input can just be copied to the output as bytes without having to be sent through a bit writer. It'll still need an endian conversion but it should be much quicker than going through the bit writer.

Assuming I haven't made another mistake.

Re: WAV to FLAC "uncompressed"

Reply #7 –
The reference encoder has an undocumented switch to always encode as verbatim, but it will still use wasted bits when it can. I don't think there is any option to switch it off, although it certainly is fine with the format.

Re: WAV to FLAC "uncompressed"

Reply #8 –
For fun I made a hacky (ie do not use except for testing, barely tested and it only works with raw CDDA input of normal lengths) verbatim-only encoder called flick that avoids using a bit reader or bit writer. Doesn't do MD5 or go back to fill in the optional things in the header, or implement any other features like seektable etc. For a close-to-apples-to-apples comparison the reference encoder needs to use these settings ( -l0 -0 -b4608 --disable-constant-subframes --disable-fixed-subframes --no-md5 --no-padding --no-seektable --no-adaptive-mid-side --no-mid-side --totally-silent --endian=little --sign=signed --channels=2 --bps=16 --sample-rate=44100 ). It's not exactly apples-to-apples because the reference encoder adds a vorbis comment with the libflac version that I haven't figured out how to disable, but close enough.

Compile from this repo with gcc flick.c -oflick -O3: https://github.com/chocolate42/flaccid

It beats the reference encoder by quite a margin on my machine, although you'd need to use a ram disk to really see the benefit because encode time is dwarfed by I/O. Flick could possibly be sped up further, very basic implementation. It uses the crc code from ffmpeg which might not be optimal, doesn't use SIMD, doesn't do byte swapping trickery (unless compiler magic), basic framewise fread/fwrite may not be optimal, etc etc.

Re: WAV to FLAC "uncompressed"

Reply #9 –
Quote from: cid42 on
not exactly apples-to-apples because the reference encoder adds a vorbis comment with the libflac version that I haven't figured out how to disable, but close enough.
IIRC that is an APPLICATION block and not a Vorbis comment block, but you can kill it afterwards with
metaflac --remove-all --dont-use-padding filename.flac
and then I suppose any size differences will be in wasted bits only?

Re: WAV to FLAC "uncompressed"

Reply #10 –
Quote from: Porcus on
Quote from: cid42 on
not exactly apples-to-apples because the reference encoder adds a vorbis comment with the libflac version that I haven't figured out how to disable, but close enough.
IIRC that is an APPLICATION block and not a Vorbis comment block, but you can kill it afterwards with
metaflac --remove-all --dont-use-padding filename.flac
and then I suppose any size differences will be in wasted bits only?


If I remember correctly, it is a Vorbis comment.  If you use ffmpeg with the bitexact flag when encoding a file, the comment is not there, as no vorbis comments are written.  If you then use metaflac to write a tag, the encoder comment is written with whatever version metaflac is, and not what libflac actually is.

Re: WAV to FLAC "uncompressed"

Reply #11 –
Quote from: Porcus on
Quote from: cid42 on
not exactly apples-to-apples because the reference encoder adds a vorbis comment with the libflac version that I haven't figured out how to disable, but close enough.
IIRC that is an APPLICATION block and not a Vorbis comment block, but you can kill it afterwards with
metaflac --remove-all --dont-use-padding filename.flac
and then I suppose any size differences will be in wasted bits only?

The only size difference should be wasted bits if the reference coder can use it yes. The exception is the last frame, because I slapped this together quick I just used the 16 bit sample count always, the reference encoder could save 2 or 1 bytes by using a common sample count or the 8 bit representation respectively. I'll fix that tomorrow.

Re: WAV to FLAC "uncompressed"

Reply #12 –
Quote from: issacibbe on
im trying to convert from WAV to FLAC 0% compressed.
simply put : i just want to convert wav to flac UNCOMPRESSED ....

You can't. FLAC is compression program, not container like mkv, for example.
It's also lossless, like ZIP and RAR are for ordinary data - what goes in, always goes out, nothing is lost, nothing is added.
It has benefits, too, like built-in checksums so you can always check if your audio data is OK, and supports tagging.
Error 404; signature server not available.

Re: WAV to FLAC "uncompressed"

Reply #13 –
Yeah, Vorbis. I was wrong. Taggers know not to delete it.

Quote from: Replica9000 on
If you then use metaflac to write a tag, the encoder comment is written with whatever version metaflac is, and not what libflac actually is.
Yep. Or more precisely, with whatever libflac version the metaflac executable uses. No way to distinguish between "encoder has been deleted" and "encoder was this".

And ... don't try to delete it with your hex editor :-o

Re: WAV to FLAC "uncompressed"

Reply #14 –
Quote from: Kartoffelbrei on
Its called LOSSLESS compression. You want that. You dont want LOSSY compression. There is no benefit using flac if you did this. might aswell keep the wav.

https://www.reddit.com/r/Soulseek/comments/19fj6oy/i_ripped_two_albums_to_flac_one_reaches_22_khz/
Are these your posts by any chance? You are stirring up quite a lot of audio communities i am in with how you delete and repost questions. ^^

honestly no, this is my first post here, and one on reddit ... i haven't posted or repeated or any of what you claim :P

Re: WAV to FLAC "uncompressed"

Reply #15 –
Quote from: issacibbe on
Quote from: Kartoffelbrei on
Its called LOSSLESS compression. You want that. You dont want LOSSY compression. There is no benefit using flac if you did this. might aswell keep the wav.

https://www.reddit.com/r/Soulseek/comments/19fj6oy/i_ripped_two_albums_to_flac_one_reaches_22_khz/
Are these your posts by any chance? You are stirring up quite a lot of audio communities i am in with how you delete and repost questions. ^^

honestly no, this is my first post here, and one on reddit ... i haven't posted or repeated or any of what you claim :P

ah ok good good. just wanted to sanity check because that guy is everywhere right now. I may resort to touching grass soon.

Re: WAV to FLAC "uncompressed"

Reply #16 –
Seriously I thought the original question was about a way to make WAV that is better than WAV, specifically the Vorbis tagging. If I understand correctly, we are not discussing WAV in a Matroska container.

I always felt WAV meta tagging for artist, title, etc. to be rather hack-ish.

The very real compromise is decode speed of WAV over FLAC preset -0, and I'm not educated on how much simpler the FLAC options could accomplish such a feat, if possible.
"Something bothering you, Mister Spock?"

Re: WAV to FLAC "uncompressed"

Reply #17 –
Wav in a flac container is what I'm talking about as it's the only interpretation of OP's question that IMO has a benefit. You get vorbis tagging and frame hashing and whatever flac tooling for a small storage overhead of 7 hundredths of a percent relative to raw wav, 7KB per minute of cdda. Aside from chunking into frames the biggest difference between the wav and the wav contained in flac stored verbatim is that flac stores in big endian and one channel at a time, where cdda and probably most wav formats store little endian with interleaved channels.

flac -0 compared to verbatim decode speed is interesting, basically -0 is probably faster normally despite being more complicated to decode because IO is the bottleneck and verbatim has more IO. But if fully in ram on say a ram disk, verbatim should win by virtue of being roughly speaking wav just shuffled a bit. But if an esp32 can comfortably decode standard flac in realtime it's a bit of a moot point. Is anyone trying to decode flac on a z80? Probably not.

Re: WAV to FLAC "uncompressed"

Reply #18 –
I made a verbatim-only decoder to answer some of these questions, it'll blow up if you try and feed it non-verbatim input. The decoder should handle arbitrary channels and multiple of 8 bit depths, but the encoder is still limited to raw cdda for now. Mode d decodes with crc checking, mode q doesn't check crc.

tl;dr ram disk verbatim decode test tubular bells part 1:
Code: [Select]
user	0m1.681s flac143 git tarball
user	0m1.454s flac133 git tarball
user	0m1.301s flac133 OS install
user	0m1.147s flick d
user	0m0.392s flick q

So crc checks seem to take the majority of the time. There's still a benefit to avoiding bit read/write. I don't know what I'm trying to show really just messing about. Time to research crc optimisation I guess.

edit: I don't know what to make of the reference timings. The tarballs compiled with -O3 (v133 with sse2, v143 no sse2, just the standard ./configure && make for both), you'd think the OS repo binary would be as generic as possible but maybe not.