Displaying 16 results from an estimated 16 matches similar to: "FW: Lossy music formats compared"
2023 Apr 15
1
Transcode lossy to further reduced lossy to stream over Icecast
Situation:?
* remote virtual server with very little storage (estimate: I can
spare about 40G for music)
* local music collection of ~80G in all sorts of formats - lossy in
varying quality, some lossless too
Vision:
* stream my whole music collection randomized so I can listen to it
anywhere
Plan/Idea:
* Locally transcode everything to one format that results in files
that are?
2023 Apr 15
1
Transcode lossy to further reduced lossy to stream over Icecast
Opus or AAC will give you comparable results at reasonable bitrates (~128k).
Though, I would suggest finding a way to get more storage. You could
upload to Backblaze B2 or AWS S3 for pennies, if your current host won't
let you upgrade.
On Sat, Apr 15, 2023 at 3:36?PM D.T. <ohnonot-github at posteo.de> wrote:
> Situation:
>
> - remote virtual server with very little
2023 Apr 16
1
Transcode lossy to further reduced lossy to stream over Icecast
I created some test samples and transcoded to FDK AAC and libopus at
fairly low bitrates - I cannot recreate what bothered me about Opus &
noisy music previously.
It also seems I cannot tease ffmpeg into encoding FDK's AAC with VBR.
As it stands, Opus clearly wins in this scenario.*
Q:
Is it possible to stream in variable bitrate?
*
ffmpeg -i "$track" -vn -ac 2 -c:a libfdk_aac
2020 Jan 08
0
Re: [PATCH] Fix lossy conversion of Content-Length
On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote:
> Actual variable holding content length is int64_t, but it was assigned
> by explicit cast to size_t. On 32-bit systems it's a lossy conversion,
> so it was replaced by casting to int64_t instead.
>
> Signed-off-by: Adrian Ambrożewicz <adrian.ambrozewicz@linux.intel.com>
> ---
> plugins/curl/curl.c | 2 +-
> 1 file
2020 Jan 09
0
Re: [PATCH] Fix lossy conversion of Content-Length
W dniu 1/9/2020 o 14:07, Richard W.M. Jones pisze:
> On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote:
>> On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote:
>>> Actual variable holding content length is int64_t, but it was assigned
>>> by explicit cast to size_t. On 32-bit systems it's a lossy conversion,
>>> so it was replaced by casting to int64_t
2020 Jan 10
0
Re: [PATCH v2] Fix lossy conversion of Content-Length
Thanks - I have pushed this now.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
2020 Jan 10
0
[PATCH v2] Fix lossy conversion of Content-Length
From a120342e0d3d20962396e6bf5bd5ac30c66b5983 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Adrian=20Ambro=C5=BCewicz?=
<adrian.ambrozewicz@linux.intel.com>
Date: Tue, 7 Jan 2020 11:07:08 +0100
Subject: [PATCH 1/1] Fix lossy conversion of Content-Length
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Actual variable holding content length is int64_t,
2011 Jan 08
0
Detecting lossy encodes
On Sat, Jan 08, 2011 at 12:54:01AM +0100, jorgen at anion.no wrote:
>
> I think we agree now on that the "find mp3 before encoding" feature would not be a good idea to implement in the flac core. As Brian pointed out, it might be a better idea to create a program that automatically checks if a flac might have been an mp3 source.
It would be more versatile to check if the
2001 Feb 27
0
[Q] Lossy compression background information book?
Does anybody have a 'net or hardcopy reference for basic information
about the sorts of compression Vorbis uses? It sounds like there's a
lot of interesting math hiding in there...
Thanks,
d.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request@xiph.org'
2011 Jan 08
0
Detecting lossy encodes
Brian Willoughby <brianw at sounds.wa.com> wrote:
> On Jan 7, 2011, at 16:27, Declan Kelly wrote:
...
>> As the human hearing can't really tell direction with lower
>> frequencies,
>> it's not as essential. This same shortcut is why most movie "surround
>> sound" systems have only one sub bass channel.
>
> In this case, you have been misled
2020 Jan 09
2
Re: [PATCH] Fix lossy conversion of Content-Length
On Thursday, 9 January 2020 17:41:58 CET Adrian Ambrożewicz wrote:
> W dniu 1/9/2020 o 14:07, Richard W.M. Jones pisze:
> > On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote:
> >> On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote:
> >>> Actual variable holding content length is int64_t, but it was assigned
> >>> by explicit cast to size_t. On 32-bit
2001 Nov 01
1
Lossy Audio Compression Research
Hello everyone,
I'm a student at the Universtiy of Delaware, and will be soon starting
some research on the effects of lossy audio compression on speech sounds. I
will be preforming test with both mp3 and vorbis.
First of all, if I use the '--ogg' switch to lame, does lame use GPSYCHO
to encode the wave, or some other psychoacoustic model (perhaps one designed for
2020 Jan 07
3
[PATCH] Fix lossy conversion of Content-Length
Actual variable holding content length is int64_t, but it was assigned
by explicit cast to size_t. On 32-bit systems it's a lossy conversion,
so it was replaced by casting to int64_t instead.
Signed-off-by: Adrian Ambro?ewicz <adrian.ambrozewicz at linux.intel.com>
---
plugins/curl/curl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/curl/curl.c
2020 Jan 09
2
Re: [PATCH] Fix lossy conversion of Content-Length
On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote:
> On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote:
> >Actual variable holding content length is int64_t, but it was assigned
> >by explicit cast to size_t. On 32-bit systems it's a lossy conversion,
> >so it was replaced by casting to int64_t instead.
> >
> >Signed-off-by: Adrian Ambrożewicz
2001 May 30
3
Lossless/lossy hybrid?
Monkey's Audio lossless compressor (currently win32 only, free but not
open-source except decoder) author is thinking to implement a kind of
audiophile-quality lossy compression which would filter "noise bits" that
are hard to encode lossless but which are (or should be) inaudible and thus
improve lossless compression (avg. 300-450kbps). I think that implementing
something like this
2019 Jan 27
0
new -l16 "extreme" compression quality setting
Hello,
I have added a new -l16 "extreme" compression quality setting to the NHW
Project.
This new -l16 quality setting is surprisingly good actually, because I find
it better on some images than -l15 quality setting whereas files size is
smaller.I notably find this new -l16 quality setting better than x265
(HEVC).
More at: http://nhwcodec.blogspot.com/
We can still save 2.5KB per