twilly
HQ, SP, LP support on VN-xx00PC (PULCOD)
Hi,
I've just tested the VN-2100PC model, and the results are:
- connection is made
- model is recogniced
- files are listed (some data is missing)
- files are not downloaded (error: "sndfile failed to open WAV file for
writing")
Quote of some commands:
----------------------------------
# ./odvr -r
Resetting...
Model: 2100PC 4
#
# ./odvr -rl
Resetting...
Model: 2100PC 4
Folder A (3 files):
Slot File Length Date Quality
1 1 00:00:00 12/31/2007 20:22:57 ?
2 2 00:00:00 12/31/2007 21:02:28 ?
3 4 00:00:00 1/02/2008 0:23:11 ?
Folder B (0 files):
Slot File Length Date Quality
Folder C (0 files):
Slot File Length Date Quality
#
# ./odvr -rd A
Resetting...
Model: 2100PC 4
Downloading "DA_0001.wav"...
Error downloading "DA_0001.wav": sndfile failed to open WAV file for writing
Downloading "DA_0002.wav"...
Error downloading "DA_0002.wav": sndfile failed to open WAV file for writing
Downloading "DA_0004.wav"...
Error downloading "DA_0004.wav": sndfile failed to open WAV file for writing
#
# ./odvr -e
Model: 2100PC 4
Downloading "DA_0001.wav"...
Error downloading "DA_0001.wav": sndfile failed to open WAV file for writing
Downloading "DA_0002.wav"...
Error downloading "DA_0002.wav": sndfile failed to open WAV file for writing
Downloading "DA_0004.wav"...
Error downloading "DA_0004.wav": sndfile failed to open WAV file for writing
#
----------------------------------
As you can see, "Length" and "Quality" fields are missing at the file
listing (-l).
First file is recorded with HQ quality. The rest with SP quality.
The worst thing is that downloading fails, so files can't be copied to the
computer.
Any idea on how to get it working? Do you need some extra info?
Additionally, the "41-odvr.rules" file provided in the tar:
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="07b4",
SYSFS{idProduct}=="020d",
ACTION=="add", GROUP="audio", MODE="0664"
doesn't seem to work, so I had to run as root. I use Fedora, and I copied the
"41-odvr.rules" file to /etc/udev/rules.d, and launched "udevcontrol
reload_rules",
and replugged the usb cable, but "ovdr" command didn't work as normal user
(the
device wasn't found). The command only works as root user.
Maybe it's necessary a more generic "41-odvr.rules" file. Or several files
(one
for each distribution).
Thank you for all your work
Original issue reported on code.google.com by [email protected] on 4 Jan 2008 at 8:07
You'll need to save to a place where you can write. I'm not sure why, as root,
it's
failing to save the file. Check permissions.
One thing that worries me is the invalid quality setting. This may also explain
why
writing the file is failing.
As for the udev file, it was designed with Ubuntu in mind. "audio" is the group
of
users who get permission to access audio devices. Change this group to what
Fedora
uses and make sure your user is in this group.
Try this updated version (624e77d4499494dab64bfddcd77d8528 odvr-r429.tar.gz)
out. It
may fix the file writing problem, and it should tell us what codes the
VN-2100PC uses
for quality settings.
Original comment by [email protected] on 7 Jan 2008 at 7:34
Attachments:
There's a new release now (v0.1.2). When you can, please see if it works for
you.
Original comment by [email protected] on 14 Jan 2008 at 2:34
I had the similar problem and it went away with 0.1.2! Thanks! But now, when
playing
the sound, it's all noise.
Model: 4100PC
Folder A (2 files):
Slot File Length Date Quality
1 1 00:00:00 1/12/2008 22:33:19 ? (7)
2 2 00:00:00 1/12/2008 23:05:14 ? (7)
Folder B (0 files):
Slot File Length Date Quality
Folder C (0 files):
Slot File Length Date Quality
Running Gutsy/x64
Original comment by [email protected] on 14 Jan 2008 at 4:53
and here's the sample of the noise
Original comment by [email protected] on 14 Jan 2008 at 5:01
Attachments:
It must be a different encoding algorithm, as I haven't seen that quality
setting
before. Can you try making recordings with different quality settings and
finding
which ones work and which don't?
Original comment by [email protected] on 14 Jan 2008 at 5:13
Hey, this is very nice! Only one mode works and that's XHQ. There's some
minor da
da da da sound noise but it works :D Thanks.
Original comment by [email protected] on 14 Jan 2008 at 5:56
Attachments:
Model: 4100PC
Folder A (5 files):
Slot File Length Date Quality
1 1 00:00:00 1/12/2008 22:33:19 ? (7)
2 2 00:00:00 1/12/2008 23:05:14 ? (7)
3 3 00:00:00 1/13/2008 21:49:38 ? (5)
4 4 00:00:00 1/13/2008 21:50:18 ? (6)
5 5 00:00:00 1/13/2008 21:50:50 ? (8) <-- Only this works
Original comment by [email protected] on 14 Jan 2008 at 5:57
That's the answer I was looking for. I will need to investigate further and
learn how
to decode these new compression formats. I'll get back to you when I can think
out
how best to solve this.
Original comment by [email protected] on 14 Jan 2008 at 6:19
I know some little programming, can you give me some links to read up on?
Maybe I
can help a tiny bit :D
Original comment by [email protected] on 15 Jan 2008 at 5:07
This problem is more of a reverse-engineering job than a programming job. If you
want, you can try following a program trace on the official windows software
with a
debugger like OllyDbg <http://www.ollydbg.de/>. Reporting a call trace and
identifying what the inner-loop functions do when downloading the files would
be helpful.
You could also try inspecting the raw USB packet data off the device with the -D
option. Normally, with the VN-960PC and older devices, audio downloads in 576
byte
chunks, has a 2 byte length indicator, followed by an audio state header
(olympusdvr.c:read_header), followed by audio samples (3 bits per sample).
Since XHQ
*almost* works (periodic beating sound), I'm willing to bet that it's a change
in the
audio state header, or removal of the audio state header in subsequent 576 byte
chunks (this information can be derived from the first audio chunk).
Original comment by [email protected] on 15 Jan 2008 at 5:39
too bad i can't read assembly nor install the cd on a x64 vista T_T, this is
one of
the reasons why i was looking for a linux solution and here it is :D i guess
the
only solution left for me is -D. Thanks.
Original comment by [email protected] on 16 Jan 2008 at 5:14
I'm checking up here, and I want to know if you tried downloading a XHQ file
with the
-D option, while saving standard error to a file? Something like:
$ odvr -d a -D 2>downloadtrace.log
$ gzip downloadtrace.log
For now, I want only one XHQ file to be downloaded. It'll be easier to work
with that
way.
Original comment by [email protected] on 22 Jan 2008 at 6:01
Although I don't have anything to add to the comments above in the way of
technical
detail, I also have a VN 2100PC with the exact same problems as above. So I
really
appreciate all the work you've put in so far and hope these issues can get
resolved soon!
Original comment by [email protected] on 22 Jan 2008 at 9:24
In that case, either of you can provide a trace for me. I'm hoping that XHQ is
just a
slight change to the audio stream. Even a one-second recording will help.
Original comment by [email protected] on 22 Jan 2008 at 9:38
Oops. Put a space around the pipe by mistake...here's the proper log
Original comment by [email protected] on 22 Jan 2008 at 11:17
Attachments:
There appears to be some junk data at the end of the block. Here's a version of
odvr
which trims this off when decoding XHQ audio. It should also print audio header
state
and the ending state. It should be the same when moving from block to block,
like:
End State: 0x0041 0x2012 0x2041
Start State: 0x0041 0x2012 0x2041
Please save standard out and standard error. Example:
$ odvr -l -d a -D > out.log 2> trace.log
$ gzip trace.log
43a27533e1e5fcaa9091ec1d7d2f465a odvr-r462.tar.gz
Original comment by [email protected] on 23 Jan 2008 at 12:15
Attachments:
That worked great - thanks! I've attached a trace for the downloading of two
files.
The XHQ works as you suggested but it still doesn't recognize the HQ setting.
Original comment by [email protected] on 24 Jan 2008 at 5:53
Attachments:
Good! One last test then. Here's the same code, but without all that noise. It
should
also refuse to download quality settings it doesn't know (HQ, SP, and LP for
your
model is not the same as HQ, SP, and LP of earlier models). If this works as it
should, I'll put a new point release on the main page.
c0c2a2c1c31f18f6f3d6350cde1a594a odvr-r464.tar.gz
Original comment by [email protected] on 24 Jan 2008 at 6:28
Heh, I forgot to attach the tarball. Here it is.
Original comment by [email protected] on 24 Jan 2008 at 6:33
Attachments:
Brilliant! It works like a charm, refusing the lower quality file was refused
and
processing the XHQ correctly.
Out of interest, any leads on why HQ/SP/LP are different and how to fix it? I'll
probably stick with XHQ for time being but having full functionality would be
lovely.
Original comment by [email protected] on 24 Jan 2008 at 6:50
I don't have any leads on these different audio formats. If you want, make a
5-10
second or so recording in each mode and do a debug trace on each one. I might
be able
to see some pattern to it, and if not then maybe someone else can.
Original comment by [email protected] on 24 Jan 2008 at 7:18
Hmmm, that's no good as the new release wont download the files. Try it on an
older
release.
Original comment by [email protected] on 26 Jan 2008 at 5:44
Sorry about that. Here's a zip file from r462 with traces and output logs for
HQ, SP,
and LP files.
Original comment by [email protected] on 27 Jan 2008 at 4:36
Attachments:
Do you know if the new version of odvr (0.1.4 ?), with the all support of
VN-3100PC
will be avaible in few days, or we will have to wait a long time ?
Original comment by [email protected] on 10 Mar 2008 at 5:29
I have no time frame for supporting all the audio formats of the newer models. I
don't have any of the newer models available to me so it may be a while. I'll
accept
patches to add support, of course :).
Original comment by [email protected] on 10 Mar 2008 at 8:00
Hmm, I installed the Windows software that is available for download at the
Olympus
website. It reports that the "A" folder contains 14 files, but does not
download them
when I request that :-| I have to search for the CD-ROM, maybe that is another
software ...
Anyway, can be maybe help by buying you a VN-2100PC or something like that?
Original comment by [email protected] on 8 Aug 2008 at 10:56