search for: squished

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 145 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050623/3460cdea/attachment.gif

Hello, I have been getting squished faxes very reliably when sending through Asterisk using txfax. It looks as if all horizontal white space has been removed. Interestingly it is perfectly repeatable, which seems to rule out timing related issues. My configuration is: Asterisk SVN-branch-1.2-r7337M spandsp-0.0.2pre21 ( though I...

I'm trying to track down the source code to Ogg Squish 0.98 for testing. If someone has a tarball somewhere (please look!) I would greatly appreciate if they could email it to me. I've searched google high and low, it apparently doesn't exist anymore. Apparently, free software *can* disappear! -- "The question is no longer between violence and non-violence; It is between

Listmates, On archlinux with emerald 0.8.2-1, the emerald theme editor windows are next to unusable. For some reason, the button edit 'Places' and 'Name' window areas are scrunched/squished way too small. Here is a screenshot: http://www.3111skyline.com/download/linux/compiz/emerald/editwindowlayoutsquished.jpg I have tried to resize them and either I don't know how, or they are stuck. Any idea how I can fix this? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochil...

Nevermind - I found it. No, it does not use Ogg encapsulation, but it does compile right off the bat. This lists itself as version 98.9, I'm guessing that means 0.98.9. If someone has a newer version, please let me know. :-) http://www.mit.edu/afs/sipb/user/mwhitson/Project/Ogg/ogg9-partial.tgz Woohoo! Vintage Xiph from 1996! What could be better? On Thu, Dec 09, 2004 at 03:38:40AM

How can I slow/speed up the combo effects? Thanks

On Thu, Dec 09, 2004 at 04:38:57AM -0800, arc@Xiph.org wrote: > Nevermind - I found it. No, it does not use Ogg encapsulation, but it > does compile right off the bat. This lists itself as version 98.9, I'm > guessing that means 0.98.9. If someone has a newer version, please let > me know. :-) I found a 98.10 version, and uploaded it:

To cite from www.xiph.org (the author's name of this text was not available on the page): The Ogg project began with a few-weekend-attempt at a simple audio compression package as part of a larger project in 1993. At the time, the software was called 'Squish'. The project and the general problem of music compression became a personal fascination, and Squish took on a life of its own

In preparing to answer a question about some yum undesired behavior, I wanted to reference fastest mirror info, but when I went to https://wiki.centos.org/PackageManagement/Yum/FastestMirror I find all the text has been squished to the right hand side of the page and made 1 word wide all the way down. The https://wiki.centos.org/FrontPage looks similar but perhaps it is a little better? Or is this an issue of looking at it with IE? Even when this disclaimer is not here: I am not a contracting officer. I do not have auth...

On Fri, Mar 27, 2015 at 4:09 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > How about only removing the scaling limit when PGO is on? I don't see the > need for this change without PGO. This is what my patch does, and it's getting into issues. With the scaling limit gone, the frequencies propagated overflow 64bits, so they need to be scaled down to a 64bit space.

I have a question about Ogg. (which, ironically, means i'm posting to the wrong list. I don't know of an Ogg list though, and if i'm posting to the wrong list, please inform and forgive me) A while back I read how some of the developers had added MIDI support to the Ogg stream format. While just in early stages, this reminded me of a thought that had been passing through my

I am attempting to remove an element in the :afterFinish callback of the "Squish" effect. This is what my call looks like. <%= link_to_remote ("X", :url => { :action => "deleteIt", :id => wc_line.attributes[''id''], :exercise_id => wc_line.attributes[''exercise_id''] },

I'm doing bwplot(x ~ y | z, ...) with lattice, but would like the z-labels to appear to the *side* of each bwplot, rather than on top... is this possible? The main reason is that my bwplots are horizontal, and as such can be nicely squished in the vertical axis (big space-saver when including in papers), but the labels "get in the way", look too large in comparison, while I have all this empty space to the side of the plots which is being wasted instead... -- Maciej Kalisiak <mkalisiak at gmail.com> http://www.dgp.t...

...my Asterisk box. I've had success, mostly, but I've had some failures, too... The most recent failure is specific to receiving from a particular fax machine -- a "Canon Laser Class 9000S". The TIF images received are readable, but the aspect ratio is stretched horizonatlly (or squished vertically). Is this a problem anyone else has seen before? Is there a workaround? Thanks, Rob

I was wooed here by this demo page for the script.aculo.us slider control: http://wiki.script.aculo.us/scriptaculous/show/SliderDemo ... but I''m looking for a slider control well adapted for use in a touch-screen kiosk application (an unusual place to put a web application, perhaps, but bear with me...) I''ve posted an example (screencast and downloadable program) here:

Hello, I have spandsp setup to accept incoming faxes and receiving tif files via Email. Using tiff2pdf, or tiff2ps -a2 or even tiffsplit, the last page of the fax is cut off and the quality of the text looks "squished". I "figure" it's a tiff parsing thing, as opposed to a problem with my spandsp installation (heh). Has anyone experienced the same thing, or can anyone recommend a "proper" way to convert fax'd tiffs to another format or even a multi-page tiff viewer for Linux?...

I am trying to figure out file(1) magic(1) for Ogg and Vorbis. (I am using file from NetBSD 1.5.1.) Currently I have: 0 string OggS Ogg data >29 string vorbis \b, Vorbis audio Some results: $ file ~/audio/kaas.* /home/reed/audio/kaas.mp3: MP3, 128 kBits, 44.1 kHz, Stereo /home/reed/audio/kaas.ogg: Ogg data, Vorbis audio /home/reed/audio/kaas.wav: RIFF (little-endian) data, WAVE audio,

...nt representation for branch probability. For blocks with 2 targets, such info can be attached at Block (source) level, thus further saving memory. >They get converted to > frequencies. For frequencies, we don't really need 64bits, as they're just > comparative values that can be squished into 32bits. It's the branch > weights being 32 bit quantities that are throwing off the calculations. Do you still see the issue after fixing bhe bug (limit without scaling) in BranchProbabilityInfo::calcMetadataWeights ? David > > > Diego.

yes -- for count representation, 64 bit is needed. The branch weight here is different and does not needs to be 64bit to represent branch probability precisely. David On Fri, Apr 24, 2015 at 12:21 PM, Smith, Kevin B <kevin.b.smith at intel.com> wrote: > FWIW. Intel compiler's profile instrumentation uses 64 bit integer counters. > We wrestled with similar problems for a long

Kevin, Maybe also look at what air quality monitoring is being done in area. https://cran.r-project.org/web/packages/RAQSAPI/vignettes/RAQSAPIvignette.html Depends what and how near, but might be something relevant there? Karl Dr Karl Ropkins Transport Studies | Environment | University of Leeds ------------------------------ Message: 2 Date: Tue, 12 Dec 2023 07:52:59 -0800 From: Bert Gunter