Skip to main content


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.
Recent Posts
Lossless / Other Codecs / Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)
Last post by ktf -
Perhaps testing ffmpeg's flac encoder will give more interesting results: that changes the blocksize depending on the samplerate by trying to keep the blocksize a certain time, sticking to the default blocksizes. That time is 105ms for most compression levels, which translates to 4608 @ 44.1kHz, 8192 @ 96kHz, 16384 @ 192kHz and 32768 @ 384kHz

With your test method I assume results are going to be "larger files for larger blocksizes"
Development - (fb2k) / Re: Wishlist for new foobar functions
Last post by Porcus -
Going by way of 32-bit .wav you have more options. You can even wvunpack to wav and refalac to ALAC and split by cuepoints.
Actually, refalac works as a .wav cue splitter too, without going by way of ALAC.

refalac -D wavfilecuesheet.cue will split the referenced .wav image into single .wav files.
("-D" is the option to "decode", but for cuesheet splitting it doesn't even need to encode. @wojak, this close enough?)
Lossless / Other Codecs / Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)
Last post by Porcus -
Yes, and one more thing with FLAC: it defaults to more padding when the signal exceeds 20 minutes. Because, apparently, it thinks that then it is more likely to be a full-album image, which might have more metadata per file, which might justify more padding per file.

Using  --no-padding --no-seektable, the two highest sample rates are 55176 bytes larger than anything else, and that's all - and it scales with -b. (Higher block size means slightly worse compression, but that is a different story.)

Other Lossy Codecs / Re: Patent expiration for E-AC3 (Dolby Digital Plus)?
Last post by kurkosdr -
F**k you, Dolby!

PS I maintain FOSS that decodes Dolby formats using FFmpeg.

The sad thing is that Dolby (along with complicit broadcast regulators) are continuing the charade of making their patented formats essential to decoding public TV signals (even ones you may have already paid for via your public broadcaster levy/TV license) under the excuse of 3D audio. As if any terrestrial broadcaster will ever broadcast 3D audio when most of them aren't even broadcasting 5.1 audio. Or as if a 50Kbps saving per stereo audio stream matters, considering HEVC 4K video requires bitrates upwards of 10Mbps (so, the savings are 0.5% of the total bitstream at best for single-language content or 1.5% at best for multi-language content, hooray!). Also, for ATSC 3.0, you need both a Dolby AC4 license and a MPEG-H 3D Audio license so no patent racket feels left out of the royalty payments.

That said, I'd rather keep this thread focused on E-AC3 patent decision, not general Dolby hate.

Is there a patent list (and anticipated expiration date) for "demuxing" the legacy stream inside the E-AC3 stream to AC3?
There is no legacy AC3 stream within the E-AC3 stream. E-AC3 decoders are required to be backwards compatible with AC3 streams, but not the other way around - AC3 decoders can't decode any part of the E-AC3 bitstream, because there is no AC3 "base payload" inside them.
Perhaps you were thinking of DTS inside DTS-HD?
E-AC3 can have a legacy AC-3 bitstream embedded in it (E-AC3 audio in Blu-Rays does have it), but I admit I was confused with regards to whether its presence is mandatory. I also remember reading that HD-DVD could convert E-AC3 to AC3 with a claimed "no loss on the base 5.1 audio" (which was a selling point back in the format wars since the legacy AC-3 bitstream can be of low bitrate), so I assumed that even if a legacy AC3 bitstream isn't mandatory, there is at least a way to extract some kind of "base payload". As It turns out, no "base payload" gets extracted and the conversion is just some clever "hybrid re-compression" method (which brings the question: Is this method covered by patents? And if yes, when do they expire? Though I admit it's a very specialized question for anyone here to know).

BTW the old AC3 Freedom Day website made a reference to an E-AC3 patent, but it's based on that old ETSI patent declaration from 2004. That's all I have.
General A/V / Re: Audacity - file formats i can edit ?
Last post by HA-User -
here is the additional command line option that i use in eac.  we put in those phrases about once per effort.  i have nowhere near the sophistication to have done that, without dave's help !!
-w "Artist=%artist%" -w "Title=%title%"   -w "Album=%albumtitle%" -w "Year=%year%" -w "Track=%tracknr%/%numtracks%" -w "Album Artist=%albumartist%"  -w "Disc=%cdnumber%/%totalcds%" -w "Genre=%genre%" -w "Composer=%composer%" -w "Performer=%albuminterpret%"  %hascover%--write-binary-tag "Cover Art (Front)=@%coverfile%"%hascover% --allow-huge-tags  -hh %source% %dest%
Lossless / Other Codecs / Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)
Last post by Octocontrabass -
* For the "traditionally known as heavy" compressors - OptimFrog (compresses to 252 MB at -10) and Monkey's (256 MB at Extra High) - sample rate does not affect file size by a single byte.
That means no compression parameters depend on the sample rate.

* FLAC: 68 kB between 16k (largest) decreasing to 192 (smallest; two higher rates slightly up again) at -5; nearly as much difference at -8. 268 MB at -8
FLAC has a seek table, and the reference encoder seems to use seek points at fixed time intervals. Since the higher sample rates have shorter play time, the seek table gets smaller as the sample rate goes up.

There is an additional factor that explains the odd high-sample-rate results: FLAC frame headers encode "common" sample rates in fewer bits than "uncommon" sample rates. The two highest sample rates you chose are not in that list of "common" rates, so at those rates there will be an extra two bytes per frame.

* TTA: 533 kB difference, size decreasing in sample rate. 267 MB.
Much like FLAC, TTA has a seek table that gets shorter when the playback length decreases. Unlike FLAC, the block size is directly controlled by the sample rate, so the size difference is at least partially explained by changes in the compression efficiency.
General A/V / Re: Audacity - file formats i can edit ?
Last post by HA-User -
hi ab, well you passed me up.  i understand what you are saying.  now if i only understood what a conversion chain is, and how to implement it.  about the only thing that i use foobar for is conversions.  dave bryant helped me get my long string of commands working for eac ripping to wavpack.

i think this conversion chain seems similar to the command that eac uses.  however, in foobar, i never set up any such string or commands.  when i convert, i right click any file or group of files that i have selected in foobar.  i then click "quick convert".

it displays a whole bunch of formats, including apple lossless 3 times.  i dont know what the difference is, but i always click the top one.  just cuz it seems to work, as far as i can tell.

i can probably do what you want me to do, if you can sorta babysit me thru it !!