avisynth creating synch probs???

[pijetro]

I load my .avs into Vdub, and extract the .wav. I create an .ac3 with ac3machine via Besweet, but when I mux the .ac3 with my .m2v, I get an irritating 1/2 second audio stretch, 'bout 20 minutes into my clip.

I'm assuming avisynth is my problem, since this was never a problem before. Perhaps it's the way I join my .avi's??

AVIsource("F:\Boki 2mnths.avi")
clip1=trim(0,2057)
clip2=trim(2058,39331).tweak(bright=40,cont=8)
clip3=trim(39332,55551)
clip1++clip2++clip3
letterbox(8,8)
fadein(50)
fadeout(20)

I'm frameserving to CCE. I've muxed with both Tmpgenc, and BBmpeg. I've also tried toolame for my audio encoding, but got the same results.

thanxxxx

[DJRumpy]

Your source file is probably at fault. What type of audio do the AVI's have. Also, what did you use to join them? I'm guessing the glitch in the audio is not at the join point?

This thread may help. https://www.videohelp.com/forum/viewtopic.php?t=159667

The example was for MPEG, but AVI will work just as well. Just get rid of the LoadPlugin line, and change the Mpeg2Source command to AVISource

[DVbuilder]

I'm by no means an expert but I have read somewhere that Avisynt uses frame 0 as start frame, while encoders like CCE uses frame 1 as starting point. Frameserving to CCE might be the problem. Check Avisynth forum at doom9 for better help....
http://forum.doom9.org/forumdisplay.php?s=92a7df89c5bcb5730dd314472a9c0a7f&forumid=33

[DJRumpy]

Getting the field order wrong will generally not cause an audio sync problem.

It is possible the tweak command is the cause, since the 30,000 frame # corresponds to about 20 minutes, give or take. I'm not familiar with Tweak though. I assume it's loaded via DLL, or part of AVISynth 2.5?

[pijetro]

DJRumpy, you're help is fantastic. Unfortunately your posting suggestion doesn't effect me.
Basically I've captured VHSc source 720x480 with Huffy at 48khz. I'm encoding for DVD thru CCE. The program above is standard issue. Basically, I've got dark scenes that need lightening up from the same movie, but the rest of the movie is fine. This seems like the best method. I've recently downloaded Avisynth 2.08, and it comes with tons of internal filters, which tweek is a part of..When I get home, I'll try the same thing, but with

Unalignedsplice(clip1,clip2,clip3).

I even tried openening up the .avs thru CoolEdit to extract the .wav, and same problems. Perhaps it is my .AVI. I'll try, try again...It's hard to tell if my source is the cause, because Huffy generally gives crappy playback.

[DJRumpy]

I guess it's way past due for me to upgrade my AVISynth docs. I'm using 2.08, but I haven't re-downloaded the command reference in months.

Can you describe this audio 'stretch' in more detail? Does the audio lose sync after that point and stay consistant throughout the rest of the video? I would still suspect source as the primary suspect. You can always preview it in VirtualDub. Get the frame number where the bark is, and isolate and/or remove that area using the Trim command. Playing it back as a smaller clip might ease your huffy playback problems. Any newer system can generally keep up with Huffman playback withotu issue, as long as the disc IO subsytem is fairly new (ATA 100 or better)

[pijetro]

Yeah, the system is up to par, so no probs in that category. As for Huffy playback, I've read on many posts that it's primarily good only for capture and not playback. Anyhoo, I guess I can try to Divx it at the synch scene to see what's the probs.

I should have mentioned it earlier, but I had about 90 frame drops, but didn't think that it was important, because while I capture in Vdub, I have the "drop frames when behind" checked. I also have the video and audio locked. It's not the first time that I've dealt with that. I've had up to 300 frame drops on a two hour movie with no problems like this. The difference this time, is that I'm using Avisynth for the first time. I used to frameserve .vdr to CCE, but was looking for speed (where's the .75 to 1.5 everybody's talking about?)....

Actually, the audio is faster by 3/4 of a second (or video slower). There doesn't seem to be a natural progression of audio tempo. I'd go as far as saying that in some cases, it seems that the audio is synched at certain spots. As if there was a variable framerate somewhere..It's next to impossible to tell where the problem starts, but let me have one more crack at it when I get home. I've used the guides off of Doom9.net for the .ac3 conversion.

I don't wanna waste any more of your time DJRumpy, so I'll try and attack the source once again...

[pijetro]

The .AVI is fine. I just played it through media player. Something's screwing up my synch, but I don't know what the heck it is??? I'll just have to guess that it's avisynth for now...

[DJRumpy]

Remember that just because the AVI plays fine, does not mean it doesn't have problems. When you convert an AVI to MPEG, you have to seperate the audio, and video into their component streams when they are fed to the encoder. This step 'unlocks' the audio and video, allowing skew when any corrupted, or unreadable frames in either are encountered. Dropping 300 frames in a capture if fine. The only time you'd notice, is if any large number of them were close together. Remember that there are 30 frames every second. Any typcial movie can have well over 150,000 frames, so 300 is just a drop in the bucket.

Huffman is fine for playback, and encoding. It's not an ideal codec for storage, as you already know, but you should be able to play it back without issue.

The speed you get in CCE will be affected by a few things, primarily processor speed, the resolution your encoding to, and the filters being used. Make sure your input AVS file is using YUY2 colorspace. You can confirm this by opening your AVISynth script ( .AVS ) file in VirtualDub, and then look at the properties. If it says RGB, then you need to add a command to convert your input to YUY2

ConvertToYUY2()

Just put that line after your source line (AVISource). You should also make sure your script is put together properly. The order in which you place your filters can impact performance as well. You can post it here if you like. We can take a look at it.

[pijetro]

Thanx DJRumpy. I'v tried recapturing the same tape, and had the same problem. It's a shot in the dark, but I think I'll dump the tweak command, and perhaps play with the levels instead. I can't see the original script causing any problems. I'll give an update when I get 'round to it. Would you personally suggest aligned or unaligned splice for a single source movie like this??

I might try out SpatialSoften in the near future, but for now, I'm not gonna go overboard on filters.
As far as encoding speed goes, I capture at 720x480, so that no resizing needs to be done, and I capture in Huffy, which is YUY2 already, and AVIsynth works in that space natively. The main reason I went to AVIsynth is to avoid the colour conversion, thus gaining some speed. Except for adding a letterbox, the maximum speed I can get is .408 in CCE. Perhaps a nice clean DVD source provides faster encodes. If there's people capping VHS sources with faster encodes, please reply!!??

I've got a P3 1ghz. Asus Cusl-2c motherboard. 60gig & 80gig w/digitals with 7200rpms. The capture card is a trusty ATI 64mb ddr VIVO.

[DJRumpy]

I always use aligned splice. It will ensure the audio is sync'd between clips. Even to the point of inserting silence if the first audio clip falls short of the video stream. I've never had need of the unaligned splice. It would be useful when you had to purposly shorten, or lengthen the video stream from one clip, and wanted to retain that ofset in the next clip.

In regards to speed, I don't have my P3 anymore. Perhaps someone else runing a 1Ghz, and CCE can give you some comparisons to guage by. Yours is running at just a hair under half the speed of mine using D1 resolutions (PIV 2.4 Ghz). It sounds about right, considering the jump in speed between your processor and mine. Ensure you run no filters for a speed test. They can impact performance in a big way.

[pijetro]

Thanx DJRumpy. It was my .avi file.

Problems fixed, but new one arised. The video is jumpy as hell. I changed the field order, but that made it jerky and jumpy. Is this script doing me wrong?? Do you see anything out of the ordinary here???

The video plays slightly jerky on my PC, but was horrible on several standalones.

When I load the .AVS in Vdub, the framerate states 29.971. Could this be a problem?? I'm ready to give up and just frameserve thru Vdub....

Help

[DJRumpy]

Paste your script here so we can take a look at it. Generally AVISynth will only be jerky on realtime playback if your doing alot of filtering. It won't impact encoding at all, other than to slow it down. If your video gets even more jerky/jumpy, then defintely leave the field order as is.

Paste your script here. Also, what is the source (dvd/vhs/broadcast, etc), and what is the source framerate?

[SLK001]

Try adding:
AssumeFPS(29.97)

If you are trying to play your .AVS script, then is might appear jerky because of the filtering that it has to do. Encode a short clip and see if the jerkiness still is present. If you have a lot of filters present, about all you can do is step through your frames to see if they appear as you want.

@DJ: The documentation for your AVISynth should be in a separate directory under the AVISynth directory. It has all the included filters. This has been so from about ver 2.06 on.

[DJRumpy]

I don't like the format for the locally installed docs. I prefer the online version. If I need any of the newest commands, I can always refer to that.

The video plays slightly jerky on my PC, but was horrible on several standalones.

When I load the .AVS in Vdub, the framerate states 29.971. Could this be a problem??

Even if the framerate was off by .1, it would not be jerky when playing back on the PC, as the PC will support any framerate. It's strange that you have input that reports the .1 extra though. Did you perform some sort of modification to your input AVI to change the framerate, or decimate/add frames? We'll just be guessing until we can see your script.

Note: If you use the AssumeFPS, it will correct your framerate to 29.97, but you should include the TRUE parameter for your audio, or you'll end up with audio that is out of sync. It should look like this:

AssumeFPS(29.97, True)

If you leave the boolean switch out (true/false), then it defaults to False, which means 'don't sync the audio'.

[pijetro]

Thanx for not giving up on me. I don't wanna give up on AVIsynth yet.

As far as capping goes, when I input 29.97, Vdub automatically rounds it up to 29.706, and Avisynth rounds it up to 29.971when frameserving. I'm at work now, but my 'puter is encoding the old .VDR to CCE method. It's a proven method for me, but slow. My capture is VHSC source (home videos), with Huffy, and with both UYVY (native), or YUY2 for colourspaces. Wav is extracted thru Cool Edit, via the .AVS file My .m2v is done with CCE, and .ac3 is done with BeSweet. Muxing done with BBmpeg, standard DVD template.
This jumpiness is happening at a time when both .AC3 and AVISynth are being tested out for the first time...
Different authouring programs produced the same jumpiness. Like i said earlier, I don't think it's field order. I've changed the flags with Restream, and the same thing gets output, but with stutter during pans, thus adding insult to injury.....

Simple enough script:

AVIsource("F:\Boki2mnths.avi")
clip1=trim(0,39334).tweak(sat=2.0,bright=35) # inexperienced camcorder guy
clip2=trim(39335,55552)
unalignedsplice(clip1,clip2)
letterbox(8,8)
fadeout(50)

I've already tried AssumeFPS(29.97), still jumpy.
So far, I haven't found documentation for bugs on the Tweak option. It's Ver. 2.08.
I'm capping video via my ATI 64mb ddr videocard, and Sound Blaster for audio.
Should I be adding AssumeFieldBased into my script?? Should I loop this script somehow??

thanxxx....

[MrKGB]

are your interlacing settings correct?
AFAIR CCE has bottom field first by default, whereas camcorders normally have top field first.

[DJRumpy]

Cam's are always bottom field first, not top field. If you get the field order wrong, it will be jumpier. I think you said you had already tried that, and it was worse when you switched it?

As far as capping goes, when I input 29.97, Vdub automatically rounds it up to 29.706

This isn't right. If you specify 29.97 in your capture settings, VDub should not be rounding it down by .2. I would examine your source file closely for these jumps to see if their in your source to begin with. Verify the input framerate of your captured file just by right clicking the AVI and looking at the properties (or use GSpot from the TOOLS section for a more accurate detail list). The tweak command shouldn't cause any sort of jump, as it only modifies chroma/luma detail.

The jump doesn't happen where your joining these two clips does it? I wouldn't use unaligned splice (clip1 + clip2 ). Use aligned splice ( clip1 ++ clip2 ).

Before adding the AssumeFPS, verify your input files framerate. You should also take your .AVS script, and drop it onto VDUB, and look at the framerate your script is putting out.

[pijetro]

Thanx everyone. Finally, I can back up all my kids videos once and for all with a system that gives me the best possible quality for the setup I have.

I led poor DJRumpy on a wild goose chase. The jittery action on my .MPG came from having my bitrate set too high in CCE. It fell within specs, but the added camera jumping didn't help. There must have been spikes (although it didn't show in bitrate viewer). I noticed that I had pts/dts underflow probs in BBmpeg, and did a little searching.

By lowering the average bit rate to 'bout 7000 k/bits, the jitters stopped. Apparantly forcing mux rate to zero also works...

Thanx for your patience guys......

[DJRumpy]

I've been missing more than I'm hitting this week

Typically CCE won't spike too far out of your specified ranges like TMPGenc tends to do. What values did you use that causing the jitters?

[pijetro]

I set it originally like this. 1st pass Q=20, min=4500, max=9500
2nd pass min=4500, max=9500, average=8500 2 pass
Advanced settings=DVDcompliant checked,top option checked(forgot the name), luminance0-255,
DAR=4:3, Timecode=00:00:00
complexity slider=50
Gop grouping=m3, m/n4, everything else unchecked.

What got rid of my chopiness was setting the passes as such:
1st pass Q=20, min=2000, max=8000
2nd pass min=2000, max=8000, average=7500 3pass
complexity slider=50
and now I'm trying a GOP grouping of m=3, m/n=5 , as suggested by Disturbed1 for purely interlaced sources, but that's encoding while I type at work...
I've notice there's no jumpiness in my movies, although half way through the DVD, it freezes and pixelates. I'll chalk that one up to a crappy standalone. Hitachi P305U...
I've also noticed now, that I don't get a warning of dts/pts underflows from BBmpeg when muxing. Many posts state
that mux rate can be set to zero, but I'm afraid this will effect my output....

[rob1]

Hey pijetro,

Glad you got help on the sync- I had no clue. DJRumpy is, however, my god. I've got one suggestion and a question- I'm doing something very similar with CCE.

Running 1 pass VBR- though Q is set at 40 (a little lower quality), min-2,000 and max-9000. However, when I change over to do a second/third pass, I select the ave. bitrate based on the bitrate CCE found in that first VBR pass. Either do the math, or I've been lazy and used 'Bitrate Viewer' (tools section). That makes more sense to me, since that's the bitrate CCE initially calculated to achieve the desired quality (20 should be high quality). Um- so that was the suggestion (inspired by some stuff on Doom).

The question- both pijetro and myself are using fairly high min- bitrate. I know many suggest 0-300 or so. BUT- I was running into some similar pixelization problems before. Going with the higher min was a last ditch attempt to stop that. However, I've been reading that too high a min may cause more problems than it solves. I know there's probably no 'definitive' answer- but any hints on whether a drop down to around 300 would be better for the min? That damn pixelization is irritating, and has cropped up even when I'm using some high ave. bitrates. It's almost a random occurance and I've had trouble pinning down the cause.

[DJRumpy]

I always suggest 300 or even 0 for MIN. It would depend on what your player tolerates. I would start with 0, and work your way up. The lower your min, the more bitrange your VBR has to play with, and the better your output as a result.

I'm suprised either of you are not having problems, changing any setting in between VBR passes is bad. Technically, you should not change anything from pass to pass. Use a bitrate calculator to get your AVG, and set your MIN/MAX to the lowest, and highest your equipment will tolerate.

If you change the quantization scale of an encode by modifying a setting, the encoder's output will be skewed as a result, because it's bit allocation optimizations were gained by the settings from the previous pass. This generally results in worse quality, or no improvement in quality regardless of what your second pass settings are. Each additional pass with the same settings would eventually help, but your working against yourself.

Think of it as taking a drive in your car. You always get X number of miles on a tank of gas, so you fill up your gas tank to get you exactly there and back (pretend we're very anal in this example ). You know this will get you exactly there and back, because you've driven this route before. Now lets say you stop half way there. During your stop, someone steals half your gas, causing you to run out. Or, if you live in Bizzaro world, and the person puts more gas into your gastank. It would go unused. A rough anology, but hopefully the point is understood

[rob1]

Yep- that's what I thought about the min, I just wasn't sure as sometimes you see different advice.

And I personally don't change anything between passes- or I try not to. Basically, the way I do it, it's like a 2 pass constant quality setting. The first pass is a 1 pass VBR, so I let CCE pick the appropriate ave. bitrate to hit the quality level I want. Then, I switch to 2 pass VBR using the resulting vaf file from that first pass. I leave all the setting the same and pick an ave. bitrate based on what the bitrate in the 'first generation' encode was. So, really nothing changes the way I do it.

You don't save file size or speed (since you're still doing two or even three passes), but I figured you get the benefits of a two pass encode while allowing CCE to pick a good ave. bitrate, rather than just sort of guessing.

It's sort of based on Bach's revision of the Robshot method- though I really ought to try and get around to trying his suggestion for finding the complexity of the material via avisynth sampling (here)

Of course- I kinda pulled it out of my but as a way of trying to avoid that pixelization thing, but it made sense to me. Which means absolutely nothing... ;o) Do you think it hurts anything to do it like this?

[pijetro]

I'll look at the Doom guides when I get home, but for now let's go over what I've done. I can't see anything wrong between the first and second passes.....
Perhaps I should have started another post, but let's get one thing ironed out first, for my sake...
The CCE manual says that on any multiple pass, a CBR or VBR encode has to go through the process in order to create the .VAF file, which of course keeps information logged about where bitrates
should be allocated for future passes. The manual also states, that the only setting that could possibly derail or void your second pass
is if the advanced settings get changed from first to second pass, or the average bitrate changes from first to second pass by some dramatic value.
Basically, (as far as I understood it) the manual says first pass and second pass need to be similar. Just don't change anything "major" in your settings. That being said, I had min. set for 4500 so that i could
bring up the average to around 7000.
Consequently, if you open the resulting .ECL file, you'll notice that CCE creates it's own avg bitrate in the text, so I assumed this is what it's gunning for. As far as the .VAF file is concerned, when I open up the advanced settings to check my video, the bitrates are pretty darned close
to my average, and there's no spikes. Running through the GOP's you can see the average Q value is 'bout 6.0, and the average bitrate now, is 6.99.

Perhaps a result of the chopiness was too high a min. bitrate, I'll have to find out more, but considering that CCE puts everything
very close to my average.

Remember, I'm shooting crappy VHSC video, so regardless of Q value, I can only assume the encoder will look at my video and say "CRAP, SCREW YOUR MINIMUM, I'VE GOTTA GIVE IT WAY MORE JUICE CAPTAIN".

I'll look further into the CCE setting and educate myself before I type any longer...

[DJRumpy]

When you use Multipass VBR mode, the first pass is done using CBR, and the AVG value you set in your encode settings. I suppose that if you set the AVG value to the value a first pass CQ mode reports, then your not changing anything. This is not the case with MIN/MAX. These can drastically affect the way bitrate is distributed in your MPEG. You should not change these from pass to pass. You should also avoid any of the CCE filters. These will change bitrate needed for each GOP. The same is true of the pulldown detection, letterbox hint, even the audio bitrate. You can change simply things like top field first. Most of the other settings could potentially change your bitrate levels.

I would still suggest you simply calculate the maximum AVG you can use via bitrate calculator, and set your multipass accordingly. No matter what first pass AVG value is reported by CQ mode, you can always do better with an exact calculated AVG, according to how much space you have available. If you are going to fit a 1:30 minute video onto DVD-R, then you know you can use an AVG of about 6534kbs with audio at 224kbs. This will give you the exact highest possible AVG setting to fill up all available space. No need to do a first pass CQ mode to get the AVG, since the calculator method has already given you the highest possible AVG you can use (in far less time too..about 5 seconds of work).

[rob1]

What I'm encoding is a little different than most- it's not movies or even TV episodes. It's soaps, so the episodes don't really 'end' per se. So it's not like I put a set length on a dvd. I had been shooting for 4 hours per dvd (half-D1 2300 ave bitrate), but sometimes I think the ave. must have been too low, because the picture would break up due to massive pixelization in spots (maybe a quarter of the dvds or less this would happen, others would be fine).

So, I switched to trying out the 1 pass VBR hoping that setting a decent quality level would end that pixelization issue. I've only cut a couple of dvds this way and it seems to be working. Ave bitrates with a quality setting of 40 have varied between 2.3 and 2.7 bitrate- I guess because of differences in the material. So what I do, encode a four hour chunk knowing I probably won't fit it all on one disk. Author with DVDLab, which allows you to trim the excess. I pick a break in the action or a scene change and trim off the end to get the whole thing to fit on the DVD. So the end result is something that takes up pretty much the whole disk but hopefully has a high enough bitrate to avoid pixelization.

The other option would just pick the highest bitrate I've found acceptable (2.7) and do a regular 2 pass. However, a lot of times I COULD use a lower bitrate and still get quality results, so I wouldn't be maxing out my disk space. The problem is not knowing at the start what bitrate will 'cut it' quality wise.

So for me, it sort of makes sense to do it this way- but only because I really DON'T have a set amount of time I want to fit on a disk. I want to fit as much as possible without it breaking up, be it 2 hours or six hours. Since my source material isn't a set length of time, choosing the length based on the quality rather than the other way around works pretty well. If I were doing movies or regular TV episodes, not so much.

(Yes, I realize it's sad I'm putting soaps on DVD!)

[DJRumpy]

LOL! I wasn't going to say anything. To each his own. If your putting tv broadcasts onto DVD, you should consider using the TRIM command. I use this method all the time for big projects with multiple captures, or sources.

This way, you cut out all commercials from your source, and you can add any number of 'virtual' capture sessions into one long video to encode. It also has the handy benefit of reporting the exact length of your encoded material. Lets say for instance, that you have 3 episodes you want to place onto DVD. For each episode, it's common to see about 15 minutes of commercials for one hour, so for these three, you could save about 45 minutes of encoded material just by removing the commercials. Lets say that your capture files are a called capture1.avi, capture2.avi, and capture3.avi for this example:

clip1=AVISource("capture1.avi")
clip2=AVISource("capture2.avi")
clip3=AVISource("capture3.avi")
clip1++clip2++clip3
segment1=Trim(3438,25220)
segment2=Trim(26382,41289)
segment3=Trim(42898,55892)
segment4=Trim(57282,22829)
segment1++segment2++segment3++segment4

The TRIM command only has two parameters. START and STOP:
Trim(startframe,stopframe)
What the above script does, is to let you cut out all of the commercials on the fly. First it takes all three of your captures, and puts them into one long video. The 'segmentX=' just assigns the non-commerical material to the segmentX variable You can call the variable whatever you want. The last line joins all of your non-commerical material together. The longest part in this process, is simply finding the START/STOP frame numbers for your commercials. I can scan through 3 hours of video in about 10 minutes. I use VirtualDub for this. Create a seperate .AVS script, with all of the segments you want combined like so:

clip1=AVISource("capture1.avi")
clip2=AVISource("capture2.avi")
clip3=AVISource("capture3.avi")
clip1++clip2++clip3

Save that script, and drop it onto VirtualDub. This way, you can get the start/stop frames for your entire video. Then all you do is create a new script like my first example, and plug in the start,stop values into the TRIM commands, adding as many 'SEGMENTx=' lines as necessary to get through all of your video. When your done, this script will report the exact play length without commercials, and as a bonus, you have no commercials in your final output, saving space, bitrate, and time. I tried an odd filter a few days ago. I was looking for a good temporalsmoother for analog sources and not finding any that didn't create more artifacts then they cured, and I decided to give an Anime filter a try called MSmooth. These Anime filters are normally so strong, they blow away all detail of a regular (real life) video. I set it to the weakest setting of '1' (the default was 7), and the result was excellent as far as video noise went. You should give it a try. It requires AVISynth version 2.5 though (No 2.0 versions available). You might give it a try to clean up your source. It will reduce the bitrate required, and help avoid the macroblocking you've said your seeing on difficult scenes: http://www.avisynth.org/users/warpenterprises/files/msmooth_25_dll_20030124.zip

[SLK001]

The TRIM command only has two parameters. START and STOP:
Trim(startframe,stopframe)

Actually, it has three parameters.
TRIM(clip,startframe,stopframe)

If your script file looked like this:

clip1=AVISource("capture1.avi")
clip2=AVISource("capture2.avi")
clip3=AVISource("capture3.avi")

FIRST_PART=clip1++clip2++clip3

segment1=Trim(FIRST_PART,3438,25220)
segment2=Trim(FIRST_PART,26382,41289)
segment3=Trim(FIRST_PART,42898,55892)
segment4=Trim(FIRST_PART,57282,22829)

segment1++segment2++segment3++segment4

then you would have had to add the "clip" parameter. I know, this is being trivial, and your script would work correctly without the clip param, but there are times when this is needed.

[DJRumpy]

The CLIP parameter is only necessary, if your input source is stored in a variable (in your example, you called it 'FIRST_PART'). By returning CLIP1++CLIP2++CLIP3 without assigning it to a variable, it makes the CLIP parameter invalid, and unecessary. This is not in contradiction with the documentation. The CLIP parameter cannot and should not be included when using my formatting. Why would you want to do more typing, and make your script more difficult to read?