Av to dv convert bug?

When I had imovie4 I was able to send my vhs recordings via my cannon750i to Imovie no problem. Then I upgraded to 5 which stopped all that. Hoping this problem would be resolved in imovie6 has also proved to be unfruitful I would just like to know why it was removed in the first place or am going to have to go back to the future and keep switching to imovie 4 for my initial transfer? If theres anyone esle with the same problem I would like to hear from you.. perhaps you know another way around the problem....
G5 Mac OS X (10.4.4) G5 2Gb Ram 2Gb

Hi John,
sorry for insisting, but it CAN be a firewire issues... it would help, you're telling us your camera model...
iMovie: Cannot See or Control Camera
http://docs.info.apple.com/article.html?artnum=43000
What to do if your computer won't recognize a FireWire device
http://docs.info.apple.com/article.html?artnum=88338
See the Sony fix here:
http://danslagle.dvmix.com/mac/iMovie/usage/5020.shtml

Similar Messages

JSF Converter - bug

When J associate my converter to HtmlDataTable(h:dataTable) in JSF(JSP) page in 'Design' tab appear problems:
1) in dataTable there isn't any column visable
2) everything below dateTable in same Panel Grid aren't visable
All this affect only 'Design' tab. In 'Source' tab everything is OK and when J run application everithing work like it should.
Is this bug or can be fixed somehow?

Hi.
J solve the problem partly and here is the problem and solution:
Problem - JDeveloper 10.1.3 have problem in showing table when code look like this:
<h:dataTable width="350" value="#{infoBean.popular}" var="popular_">
<h:column>
<f:facet name="header">
<h:panelGroup>
<h:commandLink action="POPULAR">
<h:outputText value="Najpopularnije"/>
</h:commandLink>
</h:panelGroup>
</f:facet>
<h:commandLink>
<h:outputText value="#{popular_}" converter="ProductTitle"/>
</h:commandLink>
</h:column>
</h:dataTable>
Solution - When J change code to this 'Design' tab shows the table but not the text in 'outputText'(here #{popular_}):
<h:outputText value="#{popular_}">
<f:converter converterId="ProductTitle"/>
</h:outputText>
Please try this!

HP PRIME : convert() bug in CAS mode (firmware 8151)

Hello,A bug appears when trying to convert units in CAS mode.how to reproduce: go to CAS mode,type: CONVERT(0_K,1_°C)and you will get this result : −272.15_(譕菬⓬璡扱㌁觅ﱅ譖౵譗ࡽ亊訂Ⓛ㰏甃Ⴡʹｦ謆၏ҡ抹謁袔ॄ) as you see somthing goes wrong in unit name... for info : It's the most recent firware (from july 2015) 8151.

Please let us know some examples of expressions that you tried, what you expected, and what happened instead. ALSO please let us know what modes your Prime is in (e.g. RPN Entry mode, or CAS view), because Prime behaves very differently depending on the Home Settings and CAS Settings. Which app is the currently active app (shown in the display's title bar) can also alter Prime's behavior. When you let us know these things, we'll be able to discern why you are getting syntax errors.
If I were a betting man, I'd wager a nickel that the problem is due to your Prime being in RPN mode. If so, you have to use RPN syntax, not algebraic syntax. Example: 5_ft, Enter, 1_in, Enter, CONVERT --> 60_in (just like on your HP 48). Do I win a nickel?
Disclaimer: I do not work for HP. I'm just another happy HP calculator user.
-Joe-

Shape/Path - transform/convert -bug?

I have noticed a few subtle UI changes in PShop CC -some of which seem like bugs. Here's one:
When I apply "transform" to a newly created Elipse path (which has been pre-specified as a path), I get this prompt:
"This operation will turn a live shape into a regular path. Continue?"
But the elipse I have created is NOT a shape. The Path option has alrady been selected. Yes, this is a very minor quibble, but as a former beta (and alpha) tester, I tend to be compulsively thorough! OTOH, perhaps there is a user error on my part. I did double check that new paths created with elipse tool are spec'd as "paths".
thanks

There are some issues with the new shapes. I'm not 100% sure on this but they now have "Live shapes" where you can set some of the shape/path properties like how rounded the curves are on a rounded rectangle. So I guess the elipse also has some "Live" properties. However, once you transform the shape/path, you lose the ability to edit those properties and the shape/path becomes a regualar shape/path. I suppose it would be good for them to specify in the alert what exactly on what you working - path or shape.

Convert Regions to New Sampler Track - new bug in 9.1?

I've tried creating new EXS instruments using the Audio>Convert Regions to New Sampler Track command and all I get is empty audio files, or files containing bursts of white noise.
Same thing happens in both 64 and 32-bit versions of 9.1.
The same regions create a working sampler instrument when the operation is tried in v9.02.
Can anybody confirm this apparent bug?

Bee Jay wrote:
Ok, I set my audio format to CAF, bounced some audio to a CAF, then did the convert to sampler instrument on that CAF, and it still worked fine for me.
The created slices in the EXS editor were all CAF format too.
This is at 44KHz, 24-bit. What is your sample rate etc set to?
The same - 44.1/24
Oh well, I'll report it anyway. Maybe it's hardware specific.
Thanks for your time, Bee Jay.
Michael

ITunes 6.0.4 Lossless to MP3 Convert Bad ID3 Tag Bug (Intel Only?)

Hello all,
I usually rip my CDs to Apple Lossless, name it the way I want, include Album Artwork, then switch rip preference to MP3 (224kbps), highlight the lossless files and choose "Convert Selection to MP3" in the Advanced menu. I do this to save the time of having to rip things twice.
Up through 6.0.3 it created proper ID3 tags with the album artwork just fine, but upgrading to 6.0.4 (Intel - I haven't verified this with my G4 Powerbook running 6.0.4) I do my usual process, the information is in the iTunes window, matching the Lossless files, but as soon as I delete the items from iTunes (but not the files themselves) and drag the MP3 files back to iTunes, the tracks show up in iTunes without ANY of the ID3 info, but WITH the album artwork.
The name lists the filename in the Song Name field as if there weren't any ID3 info.
The reason this came up is I rip to one drive, but keep the MP3s on another drive.
Anyone else out there with this problem/can verify this problem?
Thanks!
John V
Intel iMac 20" Mac OS X (10.4.5) 2GB RAM 10.4.5

There have been a lot of recent posts about tags not being updated properly in iTunes, and I am starting to think that it's a bug.
In your case, you might want to consider using Max to rip and encode. You can configure the application to rip your CDs and encode to multiple formats at once, using any of the iTunes encoders plus about twenty others, including LAME MP3. The tag information will remain intact, and the output files can be directly added to your iTunes library if desired.
Also, you may want to try Max's file encoding function for Apple Lossless files you already have stored on your HDD. You can batch encode them to MP3, keeping the tags and album art.

Really bad banding and artifacts in 16-bit layered greyscale file. Bad banding is retained when converted to 8-bit with No flattening. Flatten 16-bit image and banding and artifacts disappear even with no dither or noise layer. Is this a known bug?

Has anyone else experienced this?
I thought it was a monitor problem at first, but I'm using a 10-bit per channel Eizo. It seems to be a Photoshop bug based on many layers interacting with each other. When I flatten everything is fine. But I need to work on this image with layers and decent fidelity. Interestingly when I convert to 8-bit without flattening (and utilising the dither function to potentially reduce banding even further), it uses the terrible artifact laden/banding to do the conversion even though when I zoom into 1:1 in my 16-bit document it looks fine. But 50% or 25% zoom I suddenly get these awful artifacts.
Here's some screenshots to clarify. Please note I've used Photoshop for 24 years so I'm no slouch but this is the first time I've seen this. The problem is I need to do some subtle airbrush and texture work on this and it's almost unusable unless I flatten (please note, it does the same in the original 8-bit file and just to say I Gaussian-Blurred every layer with a 30px radius after converting to 16-bit so the there's no longer any 8-bit information in there or reasons for banding/artifacts). I can only think it is some of bug in Photoshop's layering engine.
Has anyone seen this before - dealt with this before?
Thanks in advance.
Not sure these embedded images will work.
8% zoomed - see all the strange banding and triangular artifacts
<a href="http://imgur.com/izrGuia"><img src="http://i.imgur.com/izrGuia.png" title="source: imgur.com" /></a>
Flattened view - all smooth:
<a href="http://imgur.com/Pn35IAK"><img src="http://i.imgur.com/Pn35IAK.png" title="source: imgur.com" /></a>
50% zoom, still there:
<a href="http://imgur.com/Z207hFd"><img src="http://i.imgur.com/Z207hFd.png" title="source: imgur.com" /></a>
100% artifacts disappear:
<a href="http://imgur.com/6aGOz0V"><img src="http://i.imgur.com/6aGOz0V.png" title="source: imgur.com" /></a>
100% 16-bit layered
<a href="http://imgur.com/0XJfe5e"><img src="http://i.imgur.com/0XJfe5e.png" title="source: imgur.com" /></a>
and finally 8-bit layered converted from 16-bit with dither.
<a href="http://imgur.com/PSxiu43"><img src="http://i.imgur.com/PSxiu43.png" title="source: imgur.com" /></a>
help!

I can't speak to why, perhaps someone more knowledgeable than I can speak to that. But if it only happens at certain views then it's purely a display issue; it won't happen in print or when you downsample to display size. Such banding issues have always disappeared for me when I output to 8 bit.
I'd assume that it's because of your monitor; it can't display all the colors and when zoomed out there's too wide of a range in a small area so banding occurs. But that's just my guess.

Acrobat 9 - Converting to PDF creates shortened lines - Bug??

I've just converted from Acrobat 8 to Acrobat 9 as part of the Creative Design Suite and now running on Windows7.
In the past I have found it extremelly convenient to print various documents (eg Hotmail - emails or printouts of a web page) to PDF files. In Acrobat 8 I had no problem when
selecting Print - to PDF to create a PDF document, which I can then file. However, with Acrobat 9 it seems that all the PDF files I create in this way have 2 unexpected and undesirable things in common:
1) all documents are displayed with huge scale factors (ie 785% or 1000%).
2) all the lines in the document are foreshortened so that only a small piece of a few characters (typically unreadable) appears in the PDF (regardless of what you then change the scale factor to) and as a result creates lengthy documents of many pages, even though the original document may have been only a single page. Interestingly, only the thing readable seems to be a file header showing the URL of the page printed.
Is there a setting that I must make in setting up Acrobat 9 so that I get an accurate recreation of the original document rather than a long thin vertical string of documents many pages long that are totally unusuable or is this a bug in Acrobat 9 running on Windows7.
Obviously, any help in this regard would be appreciated as Acrobat 9 is currently unusable.

Try checking your Firefox page setup (File > Page Setup) . I use Firefox and did a test print of this thread to pdf with no problems. I am using Firefox 3.5.2 and Acrobat Pro 9.2.
I like to save web pages electronically for reference, too. PDF files are handy, but you might also consider a Firefox add-on called ScrapBook. I have found it very useful. The files are stored as html.
This thread was odd. As soon as I sent in the above response, the question was marked as answered although it was highly improbable that my response was read within seconds!
Message was edited by: Anna Nmty

Bug in Adobe DNG Converter 7.2 RC

Adobe DNG Converter 7.2 RC (for Windows) keeps missing files. When pointing it at a folder containing many raw image files to convert (and providing a different folder as the destination for the converted files) then it won't always find all the raw files. There are no files besides the raw image files in the folder ... umm, with the possible exception of the hidden Bridge cache files, .BridgeCache and .BridgeCacheT. The destination folder initially is empty.
When this happens then I have to re-do the conversion, with the same source and destination folders selected and the Skip source file if destination file exists check-box ticked. Then DNG Converter will collect and convert the raw image files it missed in the first run. So far, I never had to perform a third run, but I frequently have to do two runs to get a folder's raw files converted. For example, in my most recent attempt there where 966 raw image files in the source folder (of the type Sony ARW, along with XMP sidecar files), and DNG Converter found 954 files in the first run and the remaining 12 in the second. The bug also occurs when the folder contains mixed types (Sony ARW and Leica DNG in my case). There is no error message or any other kind of hint that something is going wrong, so you have to check the result manually. The status line at the top of the Conversion Status window teling the number of files to convert will report the number found; if that's less than the number of raw image files available then you'll have to start a second run when the first is finished. It's easy to miss the problem, and then you may end up with some files not converted!
So far, the bug inevitably occurs when there are many raw image files in the source folder—i. e. more than 400 (and up to 1,200). When doing several attempts on the same source folder then the set of missed files will vary, i. e. it's not always the same files that get missed. It is not even always the same number; the number of missing files varies between, say, 5 and 20, i. e. approx. 0.5 - 5 % of the number of files in the folder. It seems that if the number of raw image files in the source folder is small (say, less than 300) then the bug does not happen. In my last successful attempt, I converted 263 files of type Leica DNG, and DNG Converter found them all on the first attempt.

ssprengel wrote:
Does it matter what hard-drives the files are on, whether they are missed?
No, it doesn't. There are two physical SATA hard-disk drives installed in my machine, and the error occurs no matter where the source files are. It also does not matter where the destination folder is. Usually it's on an external 3.5" drive connected via USB 2.0, but I also tried the internal drives, to no avail.
ssprengel wrote:
Does an older DNG Converter also miss files?
Gosh! To my surprise, yes it does! I just tried DNG Converter 7.1, 6.7, and 6.6, and they miss files just like 7.2 RC does. They didn't back when they were current ... or at least, I never noticed.
This seems to indicate that the culprit is not DNG Converter 7.2 RC but my machine. But then, my machine and the hard-disk drives (including the external 2 TB 3.5" USB drive) are the very same I am using for years now. I didn't change the operating system; it still is Windows XP SP3. I am also still using the same cameras as I always did for years now. The only significant things that changed recently (besides DNG Converter) are Photoshop 13.0.1 and Bridge 5.0.1.

Problem in converting reports to PDF format - bug

dear all,
There is a problem in converting the reports in PDF format.
The situation is that if we use the tool bar icon in SAP B1 to get the reports in PDF format, there are printing errors. The output PDF file does not contain the exact data that is in the report, the values are getting interchanged and mismatched.
But if we do the same using the print in the PDF option in choose from printers window as we do regular pringting, the document is printed properly.
what may be the cause for this bug like thing. How can we solve it??
please help me..
thanks and regards,
Yeshwanth Prakash

Check this SAP Note: 1089388 Incorrect value in exported PDF when Concat function is used
[https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/smb_searchnotes/display.htm?note_langu=E&note_numm=1089388]

Convert Office 2010 documents w/ Acrobat X (potential bug?)

I am doing some testing with Office 2010 (32bit) and Acrobat X on both Windows XP (32bit) and Windows 7 (64bit). I have run into the following problem when trying to convert a Word document with X:
Opening up the Word document and either using the PDF Maker printer or the Acrobat tab to convert the document to a PDF works without a hitch.
However, opening up X first and then attempting to convert the document that way will yield the a very strange error message saying that I do not have permission to open my Word document. I double checked all of the permissions on the Word document and they all checked out - plus, I am able to open it with Word.
After a bit of troubleshooting, I have tracked this issue down to our Normal.dotm - specifically - where it is stored (on our users' network drive). After moving the Normal.dotm to %appdata% or somewhere else on the local disk and modifying Word to look in this location, the conversion went through flawlessly. I took the time to double check all permissions on our network drive and they all checked out as well.
I have verified this "bug" on Windows 7 and Windows XP in our environment. Has anyone else experienced this error with a Normal.dotm on a network drive, or have I missed something here? For the time being, it seems as though Acrobat X doesnt like the Normal.dotm on a network drive.
IT_Crowd

Did you updates X or have 10.0.0? The updates are required for use with OFFICE 2010.

Found a bug in the Convert widget how to report ?

Hello, i found a bug in the default convert widget delivered by apple, how can i let them know if this bug ? (it's not crashing, it's a big calculation error)
Thanks,

Fill out and submit this form.
(23177)

BUG: Large floating point numbers convert to the wrong integer

Hi,
When using the conversion "bullets" to convert SGL, DBL and EXT to integers there are some values which convert wrong. One example is the integer 9223370937343148030, which can be represented exactly as a SGL (and thus exactly as DBL and EXT as well). If you convert this to I64 you get 9223370937343148032 instead, even though the correct integer is within the range of an I64. There are many similar cases, all (I've noticed) within the large end of the ranges.
This has nothing to do with which integers can be represented exactly as a floating point value or not. This is a genuine conversion bug mind you.
Cheers,
Steen
CLA, CTA, CLED & LabVIEW Champion
Solved!
Go to Solution.

Yes, I understand the implications involved, and there definetely is a limit to how many significant digits that can be displayed in the numeric controls and constants today. I think that either this limit should be lifted or a cap should be put onto the configuration page when setting the display format.
I ran into this problem as I'm developing a new toolset that lets you convert all the numeric formats into any other numeric format, just like the current "conversion bullets". My conversion bullets have outputs for overflow and exact conversion as well, since I need that functionality myself for a Math toolset (GPMath) I'm also developing. Eventually I'll maybe include underflow as well, but for now just those two outputs are available. Example:
I do of course pay close attention to the binary representation of the numbers to calculate the Exact conversion? output correctly for each conversion variation (there are hundreds of VIs in polymorphic wrappers), but I relied in some cases on the ability of the numeric indicator to show a true number when configured appropriately - that was when I discovered this bug, which I at first mistook for a conversion error in LabVIEW.
Is there a compliancy issue with EXT?
While doing this work I've discovered that the EXT format is somewhat misleadingly labelled as "80-bit IEEE compliant" (it says so here), but that statement should be read with some suspicion IMO. The LabVIEW EXT is not simply IEEE 754-1985 compliant anyways, as that format would imply the x87 80-bit extended format. An x87 IEEE 754 extended precision float only has 63-bit fraction and a 1-bit integer part. That 1-bit integer part is implicit in single and double precision IEEE 754 numbers, but it is explicit in x87 extended precision numbers. LabVIEW EXT seems to have an implicit integer part and 64-bit fraction, thus not straight IEEE 754 compliant. Instead I'd say that the LabVIEW EXT is an IEEE 754r extended format, but still a proprietary one that should deserve a bit more detail in the available documentation. Since it's mentioned several places in the LabVIEW documentation that the EXT is platform independent, your suspicion should already be high though. It didn't take me many minutes to verify the apparent format of the EXT in any case, so no real problem here.
Is there a genuine conversion error from EXT to U64?
The integer 18446744073709549568 can be represented exactly as EXT using this binary representation (mind you that the numeric indicators won't display the value correctly, but instead show 18446744073709549600):
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111000000000000b
--> Decimal: 18446744073709549568
The above EXT value converts exactly to U64 using the To Unsigned Quad Integer "bullet". But then let's try to flip the blue bit from 0 to 1 in the fraction part of the EXT, making this value:
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111100000000000b
--> Decimal: 18446744073709550592
The above EXT value is still within U64 range, but the To Unsigned Quad Integer "bullet" converts it to U64_max which is 18446744073709551615. Unless I've missed something this must be a genuine conversion error from EXT to U64?
/Steen
CLA, CTA, CLED & LabVIEW Champion

Bug When Converting (Back) To Local User Account

I am using Windows 8.1 Pro and began by setting up a local user account, which is the Administrator account. I then successfully switched the account to a Microsoft account, with the same user name.
As a test, I then decided to switch back to a local user account.
The bug is that I was not permitted to use the same user name. I had to select a different user name. This defeats the purpose of transparently switching a from a Microsoft account to a local account.
Fortunately (for me) I had anticipated that something might go wrong and had performed a full system backup to a external USB drive before I began this switching test.
L.M.Cohen

While Windows 8.1 (Pro) allows you to create new User accounts, it is set up to "convince" you to create Microsoft-type user accounts, rather than local user accounts.
And if you try to convert a Microsoft-type account to a local user account,
with the same user name, it will not yet you do it. However it will allow you to convert in the opposite direction,
with the same user name.
So I started all over and carefully read the small print -- to learn that you can initially set up a local user account. But this is discouraged, but if you persist, it can be done -- even though it is implied that "the sky might fall."
This is disingenuous.
However now that I understand the dynamics, I have no more problems.
Regards,
L.M.Cohen
L.M.Cohen

Bug: DNG Converter 8.6 ignoring XMP files

There seem to be a severe bug in Version 8.6 of the DNG Converter.
It just does not take over XMP data from sidecar files anymore into the generated DNGs.
As a result the previews embedded into the DNGs are flat as well, any former edits are not being applied.
Up to version 8.5 everything worked as expected, this behavior is new in 8.6.
I don't know, if this is the right place to ask - but Adobe, please fix this ASAP! Thank you!
Best Regards
Gunther Wegner

Thank you Rob and done: Bug in DNG Converter 8.6 - XMP data does not get applied

Av to dv convert bug?

Similar Messages

Maybe you are looking for