pepak

Thanks - that batch is almost what I need. Unfortunately, Tag doesn't support writing ID3v2 tags, that's about the only thing that bothers me now :-(

Can anyone recommend me an audio converter which would satisfy all of these requirements? If any such exists - I just can't seem to find it: - runs under Windows - command-line control; I would prefer a console application, but it is not required provided that the GUI can start, run and close without user's intervention - supports wildcards - converts at least FLAC into MP3 - keeps tags (as many of them as possible, including custom tags if the target format can hold them) - if it uses temporary files, they should be created in a temp directory and not in the current working directory I can do almost everything from this list just using batch files + lame + flac, but that means losing tags.

The issue is that while the new menu is far more operative than the classic menu for users who leave the menu in its default state, it is far less operative for those few of us who modify the menu to be operative. I mean, I am happy for those users who get their productivity increased by the incorporated search, but I am less happy that I am forced to use the search because the more efficient approaches have been declared obsolete and removed completely. Start + 3 keypresses was worst-case scenario for every single application in my setup. With forced search, Start + 3 keypresses is no longer the worst-case-scenario, but the best-case (don't forget the ENTER you need to actually start the program). That's what I am complaining about :-) As I said, the new start menu is pretty fast when compared to the inefficient default classic menu. It is much less appealing when you consider an optimized menu (where I could achieve the same thing with two keypresses).

Thanks for the answers. The folder structure seems like a good idea, I'll have to try it out.

Yes, I know there already is a topic for Start Menu, but it seems to have deteriorated to flames and name-calling. I would like to keep this factual, please. --- My questions: 1) Apparently it isn't possible to revert back to "classic" menu. I suppose I can live with that, but one thing I just can't stand is the new system of submenus opening within the limited space of the Start <emi; I much prefer the old system of submenus where each opens to the right of its parent, eventually filling the whole screen with menus (because it makes it very easy to see where am I in the menu hierarchy). Is it possible to get the submenus "outside the box"? 2) I am not too happy with search. It is a fine idea in principle, probably useful for many people, but not for me - as it is now, I have the menus organized in such a way it takes three (four) keypresses to start any program - e.g. [sTART] [P]rograms nternet [F]irefox. I don't mind the extra [ENTER] of the search-based Start Menu too much, but I just can't fathom how the search actually works: a) It seems to use some sort of full-text search: If I type "pad" in the search box, it finds a great number of control panel applets (none of which have "pad" anywhere in their title, as far as I can see - "View devices and printers", "Device manager", "How to add new hardware" etc.) but it doesn't find either Notepad or Wordpad. What are the criteria for finding an application? b) Another thing, the sort order seems to be somewhat "mutable" (my guess is that it will place the "most often started" applications at the top). Is it possible to change the ordering? As far as I am concerned, the optimal order would be "files starting with typed text, alphabetically, then files containing the typed text, also alphabetically" (right now, if I search for "not", I get "Sticky Notes", then "Notepad"), but I can live with anything that is fixed (I want to be able to start programs quickly, without having to look at the screen; memorizing [sTART] N O [ARROW-DOWN] [ENTER] is fine, but [sTART] N O [look at the screen and continue accordingly] is not).

Problem solved: It's a known bug in Windows XP. http://support.microsoft.com/kb/913872

I have encountered a very strange problem with huge files. I am trying to pinpoint the source of the problem. I have a FreeNAS box with 4x 1TB drives in RAID-5, giving me 3 TB of capacity (2.78 TiB). I created a file taking up almost all of the space. There is no problem whatsoever with this file on the FreeNAS. The file is accessible through SMB (Windows Shares) to other Windows machines, and here is where my problems begin: On my Windows XP SP2 machine I can read the file with two rather specialized applications but not with any other: File managers can't read the file, shell commands such as COPY and TYPE can't, hex viewers can't. I was experimenting with this file a little and found out that: 1) The problem occurs in ReadFile() API call no matter what parameters are used. The error returned is something to the effect of "not enough space to perform this operation" (I am translating from my localized Windows). 2) If I use FILE_FLAG_NO_BUFFERING when opening the file, file reads correctly if I follow the rules for reading non-buffered files. I would very much like to know if this is some known feature or bug of Windows API, if it is fixed in Vista or 64bit XP or Vista, or if it is maybe a problem in the SMB protocol (either on the side of Windows or FreeNAS). Did anyone try working with huge files like this?

I wonder: How small can I make Vista x64 while still retaining basic functionality (accessing shared folders on other computers, sharing my own folders, printing...)? Nonessential stuff such as movie maker, media player, Aero etc. can go, I can live without the drivers (I can use a version from the manufacturer, stripped to the bare bones), pagefile will be disabled and temp directories moved to a different drive, but I need to keep critical functions. Installed applications are not a problem, since I only install two or three which can not be made "portable". I have read several reports about "extreme vliting", but those seem like pointless competition rather than building a setup which will be used by an actual user. (The reason I ask: I am considering the move to 64 bits, but I have a limtied space for system partition - I use Gigabyte i-RAM which maxes out at 4 GB).

Yes, but only if you are already running a 64bit OS. Apparently you can't vLite a 64bit Vista version if you use 32bit OS (XP or Vista).

I have just tried to vLite my x64 Vista from Windows 2008 Server x64. The result? I got the same "Index was outside the bounds of the array." error as when I tried it from 32bit Vista and 32bit XP. Agaion, with both vLite 1.1.6 and 1.2. Note: I don't even get as far as "hotfix integrations, service pack integrations, language pack integration and component removals" - the error stops me while I am trying to choose the Vista directory.

So the only possible solution is to install the 64bit version, then install vLite, create a Lite installation, and reinstall? In that case, could anyone please tell me what sizes to expect after massive removals? I need to know if the Vista 64b will fit on my Gigabyte i-RAM (max. 4 GB, currently 2 GB).

I wonder, is it possible to vLite a 64bit version of Vista on a machine running a 32bit operating system? Because I just can't do it. I tried three machines now: 1) Virtual PC + Windows Vista Business 32bit: I installed vLite 1.1.6 and the WIM driver. Clicked Browse, chose the directory with V64 files. Vlite apparently entered an endless loop - it is running (the virtual Task Monitor shows it uses all of virtual CPU's power), but it is not getting anywhere after 6 hours I let it run. I upgraded to vLite 1.2 and got exactly the same result. 2) Virtual PC + Windows XP Pro Lite 32bit: I installed vLite 1.1.6 and the WIM driver. Clicked Browse, chose the directory with V64 files. Vlite asked me to choose Vista version (I chose Business), then it displayed build number and (I think - I'll get to it why I can't verify it) the directory size. Then it crashed with "Index was outside the bounds of the array." The detailed information was: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.IndexOutOfRangeException: Index was outside the bounds of the array. at .. () at ..(Int32 ) at ..(Boolean ) at ..(Object , EventArgs ) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- vlite Assembly Version: 1.2.0.0 Win32 Version: 1.2.0.0 CodeBase: file:///C:/Program%20Files/vLite/vLite.exe ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- vLite Assembly Version: 1.2.0.0 Win32 Version: 1.2.0.0 CodeBase: file:///C:/Program%20Files/vLite/vLite.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- MCDBNET2 Assembly Version: 1.3.3.33894 Win32 Version: 1.33.0.133 CodeBase: file:///C:/Program%20Files/vLite/MCDBNET2.DLL ---------------------------------------- msvcm80 Assembly Version: 8.0.50608.0 Win32 Version: 8.00.50727.42 CodeBase: file:///C:/WINDOWS/WinSxS/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd/msvcm80.dll ---------------------------------------- vhelper Assembly Version: 1.0.3064.26611 Win32 Version: 1, 0, 0, 1 CodeBase: file:///C:/Program%20Files/vLite/vhelper.DLL ---------------------------------------- msvcm90 Assembly Version: 9.0.21022.8 Win32 Version: 9.00.21022.8 CodeBase: file:///C:/Program%20Files/vLite/msvcm90.DLL ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. When I tried again, I wasn't asked for Vista version anymore and no build/size was displayed - the error appeared immediately. I tried upgrading to vLite 1.2, but got exactly the same result. 3) A real PC + Windows XP Pro 32bit: Exactly the same result as with 2, except that when installing the WIM driver, Windows complained that it can't find 100Ziper.inf file. The installation succeeded anyway. Any idea on how to create a Lite version of 64bit Vista? Thanks.

Found it: It turns out the Vista directory must be located on a local drive, not a network drive.

Unfortunately, no change. No positive change, that is - the error code changed, but the message remains :-(

I am afraid I don't know what to do anymore: No matter what I do, when I try to Apply the changes, vLite gives me the error in the title and terminates. I tried everything I could think of: - tried vLite versions 1.2 and 1.1.6, the difference being that v1.2 sometimes complains at the very beginning that it couldn't start the driver. - tried it under (all virtual, all under administrator) Windows XP (SP2 Lite), Windows XP (SP2 full) Windows Vista Business (full) - tried it on a real computer that I use for testing - tried installing the whole WAIK package before running vLite Google search returns several Mounting Image Errors, though with a different error code - and as far as I can see, all the solutions involved something I tried without success. Any ideas?